I wonder if there is a chance of Kopia using the win32 SeBackupPrivilege to bypass NTFS ACLs ?
It’s quite common for users to alter the permissions tab of files on shared network drives. Admin teams may want to restrict access to a folder, but they rarely consider making sure the Administrator user still has access. This can mean the user running kopia from the file server may not have access to those files and folder as well.
This is overcome in Robocopy with a ‘Backup Mode’ operation.
Backup mode is a way to read and write files ignoring any permissions problems.
It uses the SeBackupPrivilege (reading) and SeRestorePrivilege (writing) in order to read/write any and all files, disregarding any ACEs that would prevent you from reading or writing a file.
Normally when trying to copy or access a file, Windows performs a check to make sure you have permission to read or write to location, but with SeBackupPrivilege (granted to the Backup Operators and Administrators groups by default), and SeRestorePrivilege (also granted to the Backup Operators and Administrators groups by default), these checks are bypassed.
On domain controllers, the mentioned user rights are also available to the Server Operators group.
This user right determines which users can bypass file and directory, registry, and other persistent object permissions for the purposes of backing up the system. This user right is effective only when an application attempts access through the NTFS backup application programming interface (API) through a backup tool such as NTBACKUP.EXE. Otherwise, standard file and directory permissions apply.
This user right is similar to granting the following permissions to the user or group you have selected on all files and folders on the system:
This security setting determines which users can bypass file, directory, registry, and other persistent object permissions when they restore backed up files and directories, and it determines which users can set valid security principals as the owner of an object.
Granting this user right to an account is similar to granting the account the following permissions to all files and folders on the system:
Traverse folder / execute file
Write
To check if your account has these privileges, you can run the command whoami /priv at a command prompt.
Hmm I see that mounting a VSS snapshot fixes this (and other issues), but I can’t seem to get the example scripts to work, and my own batch / wmic scripts aren’t working. I’ll keep trying
Hi. They worked without modification. For some reason though, when I was testing from a command-prompt, the command-prompt window would disappear, and I didn’t realise it had worked, was creating and mounting a snapshot (in kopia home dir/random-id), and that kopia continued to run in the background. I also wasn’t very clear on the idea that KOPIA_SNAPSHOT_PATH causes Kopia to read from a different location than the actual source path, so I was a bit unsure it was actually using the snapshot and that the scripts worked/were valid.
I originally tried my own batch files, which I have used successfully with 7-zip to zip up in-use files, but it wouldn’t work with Kopia. Kopia gave a readSymlink or readDir error when trying to snapshot E:\ShadowCopy, where I had mounted the VSS shadow copy to with mklink /d.
On my other system (Linux), I used a script to mount the latest btrfs snapshot to a fixed directory, and I have Kopia snapshotting that directory. it runs the risk of the btrfs snapshot not being unmounted at the end and a new one failing to mount in its place next time around. I didn’t know about the KOPIA_SNAPSHOT_PATH thing overriding the source location. I might revisit that system, although it’s been working fine for some time.
While I am using the before.ps1 and after.ps1 as per the documentation, and this might be helping with sharing violations / in-use files, it is not allowing access to restricted (ACL) directories.
I am just doing some testing whereby I run kopia as SYSTEM instead. I have to copy the files from %appdata%\kopia to c:\windows\system32\config\systemprofile\appdata\roaming\kopia
actually it’s a bit more complicated than that, because I think the repo password is in the credentials store of the user - so I will instead need to run a command prompt as SYSTEM via pstools, then connect the repository, and see how I get on from there.
yeah that’s still no good.
I can’t browse into restricted directories even from the shadow copy mount. hmm.
SYSTEM can’t either - this is from psexec -s -i cmd
I am making some progress.
Adjusting the SeBackupPrivilege token of the cmd.exe process allows it to browse into the restricted directories.
Using the script from Lee Holmes | Adjusting Token Privileges in PowerShell
if I run with “powershell -file adjustpriviledges.ps1” then the powershell instance gets the priv, and not the cmd.exe that I ran the powershell command from, but I should be able to work it out from here. If I launch powershell, then .\adjusttokenpriv.ps1 SeBackupPrivilege, I can see with whoami /priv that SeBackupPrivilege is enabled, and I can then access the paths, as can any spawned processes.
I would be very easy for Kopia to include a parameter asking it to adjust it’s own tokens to have this priviledge.
