Further comments on FILE_OPEN_FOR_BACKUP_INTENT and Se{Backup, Restore}Privilege

[Jeremy Allison]

On Wed, Apr 25, 2012 at 10:23:31AM -0700, Richard Sharpe wrote:
> Hi folks,
> 
> I have been performing some testing on this. My current observations are:
> 
> 1. If someone else has the file open with an incompatible share mode,
> you cannot get access, even if you have Se{Backup,Restore}Privilege.
> However, if share modes are compatible, you can open the file even
> though someone else has it open.
> 
> 2. Se{Backup,Restore}Privileges only grant you a limit set of access
> bits. In this sense, it will only add GenericRead or GenericWrite to
> the access granted bits.
> 
> Based on this, it seems that the right place to add this check is in
> smbd_check_open_rights/smbd_check_access_rights(master)
> 
> In smbd_check_access_rights we get the rejected mask back and can use
> that to determine if we can remove specifically the access allowed by
> Se{Backup,Restore}Privilege.
> 
> However, in 3.5.x we would have to extract the bits not granted from
> Access_Requested and Access_Granted. Not hard to do ...
> 
> Of course, that involves passing in at least a bit specifiying that
> FILE_OPEN_FOR_BACKUP_INTENT was in Create_Options.
> 
> This should also allow opening directories with
> FILE_FLAG_BACKUP_SEMANTICS from a CreateFile as well.
> 
> This should also work for SMB2 since an SMB2 createfile seems to call
> through this path via  SMB_VFS_CREATE_FILE.
> 
> Further comments?

Looks like the right place. I already have BACKUP intent working
for SMB1 findfirst()/findnext(), what I'd like to do is finish
the code for opening for read/file exists with SeBackupPrivilege (as that's
the easier part to do) and then fix up the open-with-create
path (as that's the nasty one to get right with root access).

Let's talk about this @ SambaXP.

Jeremy.