Samba 3.5.x, robocopy and se_restore_privilege ...

[Jeremy Allison]

On Thu, Apr 28, 2011 at 10:35:28AM -0700, Richard Sharpe wrote:
> Hi,
> 
> I am looking into an issue with robocopy failing to copy when the
> logged into account has se_restore_privilege.
> 
> RoboCopy is getting Access is denied (STATUS_ACCESS_DENIED) when doing
> an NTCreate&X against a Samba share while the same operation against a
> Win2K08 server returns STATUS_OBJECT_NAME_NOT_FOUND. RoboCopy cannot
> proceed any further at this point. The failure is occurring in
> smbd/vfs.c:963(check_reduced_name) where we see check_reduced_name:
> couldn't get realpath for Student3/Desktop/desktop.ini (Permission
> denied).
> 
> This problem is with 3.5.6, but 3.5.8 is the same.
> 
> The actual error is coming from
> modules/vfs_gpfs.c:115(vfs_gpfs_get_real_filename)
> smbd_gpfs_get_realfilename_path returned Permission denied :-)
> 
> However, that is not really relevant, it seems to me.
> 
> I need to determine, as yet, whether or not the logged in user really
> has se_restore_privilege in the token, but I wanted to ask a more
> general question. There is some code in smbd/posix_acl.c that does
> what appears to be the correct thing when dealing with logged in users
> that have se_restore_privilege, which is to become_root across the
> operation. However, I would have expected that such a test should
> occur probably before performing any file system operation and higher
> up the stack. Is this different in 3.6.x? That is, is there a more
> central handling of se_restore_privilege in 3.6.x?

It's getting there but not there yet. I'm planning on implementing SeRestore/SeBackup
privileges completely in 3.6.x, but where x probably has to be greater
than zero :-).

Jeremy.