Samba 3.5.x, robocopy and se_restore_privilege ...

[Richard Sharpe]

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?

-- 
Regards,
Richard Sharpe