[Samba] Bug number for an old commit

Rowland penny rpenny at samba.org
Sat Jul 9 15:27:16 UTC 2016


On 09/07/16 15:20, John Mulligan wrote:
> On Thursday, July 07, 2016 01:46:59 PM Rowland penny wrote:
>> On 07/07/16 13:09, John Mulligan wrote:
>>> Hi Samba team,
>>>
>>> Digging through some old code and commits while trying to understand some
>>> ACL related behavior we found the following:
>>>
>>> https://git.samba.org/?p=samba.git;a=commitdiff;h=6dcbb84d485b8a8ccf0c3a70
>>> d9f5f7e951aaf1c6
>>>
>>> While the commit message itself provides some context the subject mentions
>>> fixing "one of the last two bugs with the full Windows ACL support"
>>> without
>>> referring to a bug number. I was hoping a dev, perhaps Jeremy himself,
>>> might remember what bug itself was.
>>>
>>> Thank you.
>>> --John M.
>> Jeremy is away this week and then when he gets back, he might not
>> remember, so it might help if you were to tell us just what your problem is.
>>
>> Rowland
>
> Thanks for letting me know, I didn't need the answer immediately.
>
> To be honest, getting the answer to this is a small part of an ongoing project
> to better understand how acls, especially when acl_xattr is enabled, behave in
> Samba. The primary question we've been looking into lately involves
> determining what conditions cause the samba-interpreted version of the posix
> acl to be visible to the end users if acl_xattr is enabled and the ntacl
> xattrs are in use on the objects.
>
> So far we've come up with the following conditions:
>
> 1. Remove security.NTACL from the object
> 2. A hash mismatch between the NTACL blob and the posix acl. Typically this is
> triggered by a change to the posix acl outside of samba
> 3. Create an NT acl on a dir that has no inheritable aces and then create a
> child object in that dir. For example, we were creating 3 aces that were set
> to apply to "This folder only."
>
> As we began investigating Case #3 we stumbled across code that tweaks the
> inheritance state of the acl that returned from the lower layer and this
> commit which seems to be when the code was first added.
>
> While I don't think these are strictly related we figured it couldn't hurt to
> ask which bug that change was for since it mentions a bug but no bug number.
>
> Case #3 is especially interesting to us because you can trigger it without
> needing shell or nfs access to the file system and it seems to grant
> additional access to the child object that the parent does not have. The
> parent's ntacl is restrictive but the posix acl that ends up on the child is
> more open (granting full control to Domain Users for example).
>
> We're leaning toward filing a bug for this behavior but we're still in the
> information gathering phase. FWIW, we've been investigating with Samba 4.2 but
> I plan to build and retest on a 4.4 version before filing anything.
>
> --John M.

After a quick scan through your post, I think you are trying to mix 
setting permissions on the Unix side and from Windows, you shouldn't do 
this. If you are going to set permissions on a samba share, do it one 
way or the other, not a mixture of both, the best way is to do it from 
windows and forget Unix, see here for more info:

https://wiki.samba.org/index.php/Shares_with_Windows_ACLs

Rowland



More information about the samba mailing list