[Samba] Samba not implementing "rights" correctly on server. Shouldn't it use "Capabilities" or equiv?

[Linda W]

(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