Backing up files without having to alter the file's security

Question

I'm working on a MS Windows-based backup solution. For the NTFS file system, we're using BackupRead and BackupWrite APIs to do it, and by-and-large things work. There are exceptions. We know to adjust the token privileges to obtain SE_BACKUP_NAME, SE_RESTORE_NAME and SE_CHANGE_NOTIFY_NAME privileges. We know to use ACCESS_SYSTEM_SECURITY, BACKUP_SEMANTICS and POSIX_SEMANTICS when opening the file. We know to add WRITE_DAC and WRITE_OWNER on the file to enable BackupWrite. We've stumbled through all of that. Mostly, we're good.

There are occasional files we encounter that have explicit deny for Everyone in their security descriptors, and we trip over these files when trying to open them for BackupRead. In particular, we get Access Denied (5) as an error code on the GetLastError after failing to open the file using CreateFile. I am guessing the explicit deny gets evaluated ahead of the administrators group's allow.

Being an administrator, we know we could wrest ownership away, at least temporarily. This seems heinous and I'm casting around for alternatives. I'd like to believe we shouldn't have to modify a file's security to back it up. More generally, I thought we'd just sail past everything DACL-related by getting the SE_BACKUP_NAME privilege and using BackupSemantics on the CreateFile call...but this just doesn't seem to globally apply.

I was just reading about AdjustTokenGroups, and am about to investigate possibly clearing the SE_GROUP_ENABLED attribute for the Everyone group. This seems wrong, too. I cannot help but feel like we're running down the wrong rabbit holes and so I'm casting this question out for advise. Have we overlooked something simpler?

The things we're having immediate problems with are the junctions that were introduced at the XP-to-Vista timeframe. We're trying to backup "just the junction"...as we're already successfully backing up things at the junction's target. We're adding FILE_FLAG_OPEN_REPARSE_POINT to accomplish the read.

Answer 1

The problem, I guess vaguely stated, was that we're not able to back up certain entities on the disk. However, I made an erroneous assumption. The problem was not in the CreateFile call to open the directory...but in the subsequent BackupRead call. Junctions don't apparently play well with BackupRead.

But after figuring that I can actually open the junction, I have alternative ways of recording the junction information. There is a DeviceIOControl call that will get the reparse data out of the junction point. This gives a good example of how.