[Samba] Bug number for an old commit

John Mulligan
Sat, 09 Jul 2016 14:20:00 -0000

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.