Prev: [Samba] smbcontrol -d 3 smbd reload-config permission denied message.
Next: [Samba] Some Xp Client do not save Profiles
From: Jeremy Allison on 21 Jul 2010 14:50 On Wed, Jul 21, 2010 at 08:15:35AM -0400, John Mulligan wrote: > Hello List, > > I've run into an interesting situation and am wondering if this is by > design or just an interesting side effect: using both acl_xattr and > a user in the "admin users" list at the same time seem to conflict. > > I have a tool that is running on a windows box that needs full access > to files on a given share while ignore individual file and folder > permissions. We were able to make that tool run as an > "admin user" in smb.conf. > > When I run the tool with the vfs xattr_acl module turned on (for best > compatibility with nt acls), the tests fail but when using only straight POSIX > acls the test works. Running things manually, it appears that running > with only POSIX acls the root user on the samba side is able to read/write > any file as expected, but with acl_xattr turned on samba is doing some > internal checking of the xattr acls and blocking access to the files. > > So my question is, is this by design or is this something that the > samba team would consider as a bug/feature request? > Also feel free to tell me "you're doing it wrong" if there is a better > way to provide read/write access to the windows side regardless of > the acls on the files. None of my searches turned up anything relevant, > but its always possible that I was looking in the wrong direction. > > Thank you for your time and the great software. Sounds like a bug to me. Setting "admin user" should mean your token is root and should override the ACL specific checks. Can you log a formal bug @ bugzilla.samba.org and be specific on how you reproduce the failure to modify the file/directory. Thanks ! Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: Jeremy Allison on 10 Aug 2010 20:30 On Wed, Jul 21, 2010 at 08:15:35AM -0400, John Mulligan wrote: > Hello List, > > I've run into an interesting situation and am wondering if this is by > design or just an interesting side effect: using both acl_xattr and > a user in the "admin users" list at the same time seem to conflict. > > I have a tool that is running on a windows box that needs full access > to files on a given share while ignore individual file and folder > permissions. We were able to make that tool run as an > "admin user" in smb.conf. > > When I run the tool with the vfs xattr_acl module turned on (for best > compatibility with nt acls), the tests fail but when using only straight POSIX > acls the test works. Running things manually, it appears that running > with only POSIX acls the root user on the samba side is able to read/write > any file as expected, but with acl_xattr turned on samba is doing some > internal checking of the xattr acls and blocking access to the files. > > So my question is, is this by design or is this something that the > samba team would consider as a bug/feature request? > Also feel free to tell me "you're doing it wrong" if there is a better > way to provide read/write access to the windows side regardless of > the acls on the files. None of my searches turned up anything relevant, > but its always possible that I was looking in the wrong direction. Ok, is this with 3.5.x ? If so, it's a bug - one that has been fixed in the 3.6.0 code tree. The function smb1_file_se_access_check() in 3.5.x is directly called from the acl_xattr module, and this code doesn't taker into account the admin_user status of the calling user. In 3.6.0 and above, the admin_user status check has been moved directly into the smb1_file_se_access_check() function so that it's consistent will all calls for access checking. Let me know if you want this fix back-porting to 3.5.x, if so, log a bug at bugzilla.samba.org and I'll create the patch (it's a reasonably simple fix). Jeremy. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
From: John Mulligan on 12 Aug 2010 16:40
On Tuesday 10 August 2010 20:26:24 Jeremy Allison wrote: > On Wed, Jul 21, 2010 at 08:15:35AM -0400, John Mulligan wrote: > > Hello List, > > > > I've run into an interesting situation and am wondering if this is by > > design or just an interesting side effect: using both acl_xattr and > > a user in the "admin users" list at the same time seem to conflict. > > > > I have a tool that is running on a windows box that needs full access > > to files on a given share while ignore individual file and folder > > permissions. We were able to make that tool run as an > > "admin user" in smb.conf. > > > > When I run the tool with the vfs xattr_acl module turned on (for best > > compatibility with nt acls), the tests fail but when using only straight > > POSIX acls the test works. Running things manually, it appears that > > running with only POSIX acls the root user on the samba side is able to > > read/write any file as expected, but with acl_xattr turned on samba is > > doing some internal checking of the xattr acls and blocking access to > > the files. > > > > So my question is, is this by design or is this something that the > > samba team would consider as a bug/feature request? > > Also feel free to tell me "you're doing it wrong" if there is a better > > way to provide read/write access to the windows side regardless of > > the acls on the files. None of my searches turned up anything relevant, > > but its always possible that I was looking in the wrong direction. > > Ok, is this with 3.5.x ? > > If so, it's a bug - one that has been fixed in the 3.6.0 code > tree. The function smb1_file_se_access_check() in 3.5.x is > directly called from the acl_xattr module, and this code doesn't > taker into account the admin_user status of the calling user. > > In 3.6.0 and above, the admin_user status check has been moved > directly into the smb1_file_se_access_check() function so that > it's consistent will all calls for access checking. > > Let me know if you want this fix back-porting to 3.5.x, if > so, log a bug at bugzilla.samba.org and I'll create the > patch (it's a reasonably simple fix). > > Jeremy. Yes it is, and a backport to 3.5.x would be greatly appreciated. I had opened a bug earlier when you first replied to my email, which I must have failed to reply back to. Sorry for any confusion. The bug is located here: https://bugzilla.samba.org/show_bug.cgi?id=7581 Thanks again for the assistance. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba |