[prev in list] [next in list] [prev in thread] [next in thread]
List: samba-technical
Subject: Samba 3.5.x, robocopy and se_restore_privilege ...
From: Richard Sharpe <realrichardsharpe () gmail ! com>
Date: 2011-04-28 17:35:28
Message-ID: BANLkTinP3WuAiP5yQ-fLc6XrDuSQm7QtJg () mail ! gmail ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic