Linda W
2010-Jun-23 00:22 UTC
[Samba] Samba not implementing "rights" correctly on server. Shouldn't it use "Capabilities" or equiv?
On Sunday 20/06/2010 at 10:52 pm, L. A. Walsh wrote:>> I assigned the "TakeOwnerShip" right ['Domain Admins']. >> I placed myself in that group. >> >> when I try taking ownership of [a] directory [owned >> by someone else, it] fails with a permission denied. >> >> [Why doesn't this work?] >> >> If domain rights DON't work this way -- they what are they for?someone (privately, so name withheld) responded:> Remember, the under lying file system is still in control. So, you need > to check the acl. Honestly, the best way to control samba acls is to > set the base unix acls to as close to 777 as you can tolerate, then > control everything with acls. At least that's been my experience. > > However, my experience also says that for file manipulation from > Windows, a user mapped to root is the cleanest solution. Admin group > user really seems more a permission thing for control of the Windows > side of things.---- How is this not broken? smbd is running as root. If I allocate the 'take ownership' right to an account and 'smbd', running as root, is implementing my policies on my server, then why isn't this, for the purposes of this operation (take ownership), giving the subprocess the "CAP_CHOWN" capability (or just using 'root' CAP, if "sub-CAPS" are not defined) to implement policy? Or to respond to the responder -- the underlying file system should not be in control -- since I allocated the equivalent of CAP_CHOWN for the purposes of allowing me to "Take Ownership" to an account. Smbd, running as root should override local file system permissions in this case. Is there a reason why it shouldn't? It's a root-level process, and I've told it to grant that 'right' -- I'd expect it to grant sufficient capabilities to a sub-process in order for it to k
Linda W
2010-Jun-23 00:25 UTC
[Samba] Samba not implementing "rights" correctly on server. Shouldn't it use "Capabilities" or equiv?
(oops...end truncated, on prior) On Sunday 20/06/2010 at 10:52 pm, L. A. Walsh wrote:>> I assigned the "TakeOwnerShip" right ['Domain Admins']. >> I placed myself in that group. >> >> when I try taking ownership of [a] directory [owned >> by someone else, it] fails with a permission denied. >> >> [Why doesn't this work?] >> >> If domain rights DON't work this way -- they what are they for?someone (privately, so name withheld) responded:> Remember, the under lying file system is still in control. So, you > need to check the acl. Honestly, the best way to control samba acls > is to set the base unix acls to as close to 777 as you can tolerate, > then control everything with acls. At least that's been my experience. > > However, my experience also says that for file manipulation from > Windows, a user mapped to root is the cleanest solution. Admin group > user really seems more a permission thing for control of the Windows > side of things.---- How is this not broken? smbd is running as root. If I allocate the 'take ownership' right to an account and 'smbd', running as root, is implementing my policies on my server, then why isn't this, for the purposes of this operation (take ownership), giving the subprocess the "CAP_CHOWN" capability (or just using 'root' CAP, if "sub-CAPS" are not defined) to implement policy? Or to respond to the responder -- the underlying file system should not be in control -- since I allocated the equivalent of CAP_CHOWN for the purposes of allowing me to "Take Ownership" to an account. Smbd, running as root should override local file system permissions in this case. Is there a reason why it shouldn't? It's a root-level process, and I've told it to grant that 'right' -- I'd expect it to grant sufficient capabilities to a sub-process in order for it to implement policy. Linda