Samba 3.5.x, robocopy and se_restore_privilege ...
realrichardsharpe at gmail.com
Thu Apr 28 11:35:28 MDT 2011
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
This problem is with 3.5.6, but 3.5.8 is the same.
The actual error is coming from
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?
More information about the samba-technical