/cc @alexbrainman

Go already uses FILE_FLAG_BACKUP_SEMANTICS in some CreateFile calls (e.g. Readlink, Utimes, UtimesNano, from issues #8090 and #10804) but not in other cases (notably Open). So it's inconsistent.

We only use FILE_FLAG_BACKUP_SEMANTICS to open directories and symlinks. There is no way to open them without FILE_FLAG_BACKUP_SEMANTICS flag. We do not use FILE_FLAG_BACKUP_SEMANTICS to open files, because everything we do with files work just fine without FILE_FLAG_BACKUP_SEMANTICS.

I would like to request that FILE_FLAG_BACKUP_SEMANTICS is added to the Open call in src/syscall/syscall_windows.go.

Why? What is broken if we don't do that?

this would allow Go users to open files on disk, in those cases where their permission to do so comes via SE_BACKUP_NAME instead of windows ACLs.

I did not understand this explanation. Please try again.

Thank you.

Alex

I did not understand this explanation. Please try again.

A backup program should be able to back up all files on the system.

But, a backup program must run as a certain Windows user, and it's possible that there are some files that the backup user account does not have permission to access, according to the normal ACL permission system.

Windows has a solution for it: You can open a file if either (A) you have normal ACL permissions to do so, or (B) your user account has SE_BACKUP_NAME privilege and the FILE_FLAG_BACKUP_SEMANTICS flag was passed to CreateFile.

Passing this flag does not change behaviour in the normal case. It only increases the functionality. So, I don't think there's any harm in passing this flag unconditionally.

What is broken if we don't do that?

Right now, it's difficult to write backup programs in Go that take advantage of SE_BACKUP_NAME to access all files on the system.

A backup program should be able to back up all files on the system.

Thank for explaining.

Passing this flag does not change behaviour in the normal case. It only increases the functionality. So, I don't think there's any harm in passing this flag unconditionally.

I am not security expert, so I would not know if there is a downside to FILE_FLAG_BACKUP_SEMANTICS. So I googled around, and I cannot find anything particular for or against that change. Maybe you could provide some reference explaining why it is safe to use FILE_FLAG_BACKUP_SEMANTICS all the time? Without such reference I cannot support your proposal.

Right now, it's difficult to write backup programs in Go that take advantage of SE_BACKUP_NAME to access all files on the system.

You can call syscall.CreateFile directly. Not many people write backup programs, so people who do, would have to jump through the hoops that Microsoft creates. Sorry.

Alex

I made some experiments with patching syscall to add this feature, but actually it breaks a lot of things.
I withdraw my request.