[Samba] Bug number for an old commit

[Jeremy Allison]

On Sat, Jul 09, 2016 at 10:20:00AM -0400, 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.

This looks like the issue Ralph just posted a patch for
(and I'm reviewing :-). Sorry for not getting to it in
time. I didn't actually remember the bug number. At the
time the comment "last two bugs with the full Windows ACL support"
probably didn't have proper bug reports attached and just
lived in my head.

That's why we're a little more formal about code changes
being attached to bugs now :-).

Cheers,

	Jeremy.