WinFile screwing up NTFS permissions on Paste

[29039]

I was RDP into my PC and copy & paste a .dll file across to work with my app. Instead of pasting using the File Explorer as I typically would, I was feeling Nostalgic and used the Paste function in WinFile.

After a bit of troubleshooting why my app wasn't working, I found that there were "Access Denied" errors on that file when using procmon to view it.

This was very strange, especially considering that the app was running as SYSTEM.

I figured out, there is something in the way that WinFile pasted the file which made it give the pasted file explicit permissions which weren't quite right as opposed to just allowing inheriting.

C:\Test>icacls *.dll
test_paste_using_winfile.dll NT AUTHORITY\SYSTEM:(F)
        BUILTIN\Administrators:(F)
        MY-PC\Administrator:(F)

test_paste_using_fileexplorer.dll NT AUTHORITY\SYSTEM:(I)(F)
         BUILTIN\Administrators:(I)(F)
         BUILTIN\Users:(I)(RX)

[craigwi]

Interesting. What are the acls of the file in the source location? It may not matter, but I'm curious.

[29039]

The source is a clipboard paste over RDP. On the source PC which the RDP client is running it does not matter where, i.e. C:\files\ would be the same.

[29039]

It is possible that rdp (rdpclip.exe?) creates the file in a temporary location i.e. the user's %temp% folder before putting it into the requested location, but I haven't tested it so I am not sure.

[craigwi]

Another thing I thought of: WinFile uses a very old clipboard format; perhaps older format (which Explorer does not use) triggers the different behavior.

[malxau]

@29039 Can you confirm this is a copy rather than a move?

WinFile was designed for NT 3.x (or earlier.) Windows 2000 added inherited ACLs. Renames do not manipulate ACLs - the ACL of the source file is retained in the target name, and the parent's ACL is ignored. Explorer has extra code to call SetNamedSecurityInfo to force inheritable parent ACLs to be applied. WinFile doesn't have this code, since by Windows 2000 updating it wasn't a priority.

[29039]

@29039 Can you confirm this is a copy rather than a move?

WinFile was designed for NT 3.x (or earlier.) Windows 2000 added inherited ACLs. Renames do not manipulate ACLs - the ACL of the source file is retained in the target name, and the parent's ACL is ignored. Explorer has extra code to call SetNamedSecurityInfo to force inheritable parent ACLs to be applied. WinFile doesn't have this code, since by Windows 2000 updating it wasn't a priority.

I tested again while RDP to a Windows 11 box while running process monitor.

Steps:

1. Copy file from Explorer running on Local PC (Windows 10)
2. Paste file inside WinFile running on Remote PC via. RDP (Windows 11)
3. File gets put into the remote PC's %TEMP% folder, permissions are correct (Inherits from the parent)
4. Pop-up from WinFile itself displays at the same time:

[Confirm Mouse Operation [X]]
Are you sure you want to move the selected files or directories to C:\IT-Disks?
[Yes] [No]

5. This was a Copy operation from Local PC to Remote PC via RDP, but perhaps the "Move" message is related from "Moving" the file from %temp% to the intended destination.
6. Press Yes
7. No inheritance on the file taken from %temp% anymore, just explicit permissions.