[Feature Request] Implement Security Bypass Privileges (Backup/Restore)

[greydawn]

https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx

I am attempting to do a file sync of multiple directories that have have a Deny-Write permission for "NT AUTHORITY\Everyone". In this scenario FreeFileSync fails with errors, possibly because CopyFileEx does not support reading/writing files with backup privileges (SE_BACKUP_NAME / SE_RESTORE_NAME). Errors look like this:

Error: Cannot copy file
"\\BranchServer\Share\Folder\file.ext" to
"\\CentralServer\Share\Folder\file.ext.ffs_tmp".
Error Code 5: Access is denied. (CopyFileEx)

Please consider using an alternate Read/Write scheme that CopyFileEx so that security checks can be bypassed.

[Zenju]

> SE_BACKUP_NAME SE_RESTORE_NAME

Both privileges are requested before copying a file, however for the privileges to be granted, admin rights are needed in general.

[greydawn]

I have tested this both interactively and in batch mode. Interactively FreeFileSync is being run using an elevated admin account on the local machine that is also a full administrator on both the source and destination file shares. In batch mode the scheduled task is marked to run with the highest privileges again using a highly privileged (essentially Enterprise Administrator) account.

In my research the CopyFileEx function does not honor the SE_BACKUP_NAME and SE_RESTORE_NAME privileges. You would need to use different Win32 API calls to read/write the files using those privileges. I would be more than happy to help test any changes.

[Zenju]

> In my research the CopyFileEx function does not honor the SE_BACKUP_NAME and SE_RESTORE_NAME privileges.

What makes you think so?

[greydawn]

https://technet.microsoft.com/en-us/library/aa363852.aspx

There is no mention of backup/restore privileges in this function documentation. There is a community post on the page indicating it doesn't work.

On the other hand, CreateFile very explicitly supports this feature according to the documentation (check out the flag FILE_FLAG_BACKUP_SEMANTICS):

https://technet.microsoft.com/en-us/library/aa363858.aspx

Additionally, see this relevant postings on copying data using these privileges:

http://stackoverflow.com/questions/11113097/what-is-wrong-with-this-sebackupprivilege-backup-mode-implementation

Admittedly this is a bit thin. To hopefully assist I've created a Procmon capture of the relevant activity but I'm hesitant to attach it here in a public forum. Please let me know how I can get this to you. I've also confirmed that I can reproduce the error while FreeFileEx is running with SeBackupPrivilege and SeRestorePrivilege both Enabled according to Procexp.

[greydawn]

https://technet.microsoft.com/en-us/library/aa363852.aspx

There is no mention of backup/restore privileges in this function documentation. There is a community post on the page indicating it doesn't work.

On the other hand, CreateFile very explicitly supports this feature according to the documentation (check out the flag FILE_FLAG_BACKUP_SEMANTICS):

https://technet.microsoft.com/en-us/library/aa363858.aspx

Additionally, see this relevant postings on copying data using these privileges:

http://stackoverflow.com/questions/11113097/what-is-wrong-with-this-sebackupprivilege-backup-mode-implementation

Admittedly this is a bit thin. To hopefully assist I've created a Procmon capture of the relevant activity but I'm hesitant to attach it here in a public forum. Please let me know how I can get this to you. I've also confirmed that I can reproduce the error while FreeFileEx is running with SeBackupPrivilege and SeRestorePrivilege both Enabled according to Procexp.

Based on my analysis of Procmon, this is what I'm seeing.

1. There are 10 calls being made to the source file starting with a CreateFile. These are all marked as SUCCESS and appear to be getting data and properties of the source file.

2. 15 CreateFile calls are being called in a row to create the destination file in a directory that has an Everyone/Deny permission. These all result in ACCESS DENIED. Here is what Procmon generally reports as detail for these calls:

Desired Access: Generic Write, Read Data/List Directory, Read Attributes, Disposition: Create, Options: Sequential Access, Non-Directory File, Attributes: HSA, ShareMode: None, AllocationSize: 0

3. 5 additional calls are being made to the source file beginning with a CloseFile and then an immediate CreateFile and some other operations. Presumably this is gathering the ACL to be copied over. These calls result in SUCCESS and a couple of BUFFER OVERFLOW which is probably not relevant.

4. 2 additional calls are made to the destination file... presumably to write the ACL. These result in a NAME NOT FOUND message since the file was never actually written in #2. However, based on the detail we can see that at this point FFS is trying to use the SeRestorePrivilege:

Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open For Backup, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a

---

So I would say the issue appears to be the SeRestorePrivilege is being used during the security descriptor sync but not during the file data sync.

[Zenju]

I think you're right with CopyFileEx not using FILE_FLAG_BACKUP_SEMANTICS internally. I had a look at the assembly and none of the internal calls to CreateFileW or NtCreateFile specified FILE_FLAG_BACKUP_SEMANTICS or FILE_OPEN_FOR_BACKUP_INTENT respectively.

> Admittedly this is a bit thin. To hopefully assist I've created a Procmon capture of the relevant activity but I'm hesitant to attach it here in a public forum. Please let me know how I can get this to you. I've also confirmed that I can reproduce the error while FreeFileEx is running with SeBackupPrivilege and SeRestorePrivilege both Enabled according to Procexp.

You can find my email address in FFS's about dialog. Please also add the name of the file you were copying, source and target paths, so that I can find the relevant section quickly.

Let's make a little test:
1. Here's a version of FFS using CreateFile + FILE_FLAG_BACKUP_SEMANTICS + BackupRead/BackupWrite:
[404, Invalid URL: https://freefilesync.org/FreeFileSync_7.1_test_Windows_Setup.exe]

Is this working for you? If not, any difference in the Procmon trace?

2. Are you on Windows 8 or later? Win 8 uses CopyFile2 as default copy routine, we could test if this makes a difference.

[greydawn]

I received the same results from the test build. Please let me know if you did not receive both event captures I sent you via email.

[Zenju]

So CreateFile + FILE_FLAG_BACKUP_SEMANTICS alone can be ruled out as the (only) solution to the problem. I assume you checked that FFS had SeBackupPrivilege/SeRestorePrivilege enabled and was running elevated.

Just for reference, you do have a positive test case (copying with Windows Explorer?) and we're not trying the impossible? In this case the task is to find out what Explorer does differently than a mere CopyFileEx or stream-based copying with CreateFile + FILE_FLAG_BACKUP_SEMANTICS. ProcMon may be helpful in this regard, but it's also incomplete, e.g. flags like FILE_FLAG_BACKUP_SEMANTICS are not logged.

[Zenju]

Wait, the pml file you sent is supposed to be from the test version above? In this case it wasn't running the new copy routine, but this version here should:
[404, Invalid URL: https://freefilesync.org/FreeFileSync_7.1_test2_Windows_Setup.exe]

[greydawn]

Wait, the pml file you sent is supposed to be from the test version above? In this case it wasn't running the new copy routine, but this version here should:
[404, Invalid URL: https://freefilesync.org/FreeFileSync_7.1_test2_Windows_Setup.exe]

My apologies for taking so long to respond. I finally tested this latest version (FreeFileSync 7.1 Build: May 15 2015 - Unicode x64) and it was able to successfully sync missing files to a folder that had a Deny ACE set. So yeah, the new copy routine fixes the "problem" I identified at the beginning of this thread.

I'll look forward to an official release that includes this fix.

[Zenju]

Good, I've included the changes for the next version. Here's the new beta for testing:
[404, Invalid URL: https://freefilesync.org/FreeFileSync_7.1_beta_Windows_Setup.exe]