[Samba] Bug number for an old commit

[John Mulligan]

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.