Permissions incorrectly ordered on Windows after disabling inheritance

[Jeremy Allison]

On Tue, Aug 28, 2012 at 09:42:57AM -0700, Jeremy Allison wrote:
> On Mon, Aug 27, 2012 at 08:47:31PM -0700, Jeremy Allison wrote:
> > On Mon, Aug 27, 2012 at 08:16:40PM -0700, Jeremy Allison wrote:
> > > On Mon, Aug 27, 2012 at 08:05:06PM -0700, Richard Sharpe wrote:
> > > > On Mon, Aug 27, 2012 at 6:49 PM, Jeremy Allison <jra at samba.org> wrote:
> > > > > On Mon, Aug 27, 2012 at 04:59:34PM -0700, Richard Sharpe wrote:
> > > > >> On Mon, Aug 27, 2012 at 4:29 PM, Walkes, Dan <dwalkes at tandbergdata.com> wrote:
> > > > >> > Awesome!  Thanks!
> > > > >>
> > > > >> Looks like the problem is in lib/secdesc.c:se_create_child_secdesc. It
> > > > >> needs to make an ordering pass over the ACL in the SD to ensure that
> > > > >> the ACEs  are ordered correctly. At least that is the case in the
> > > > >> Samba 3.5.x code, and I don't think there has been much change there
> > > > >> in 3.6.x.
> > > > >
> > > > > Actually, looking more closely at this I think it's a pretty
> > > > > simple bug in that I just forgot to set the SEC_ACE_FLAG_INHERITED_ACE
> > > > > on inherited ACE's when I create them :-).
> > > > >
> > > > > Should have a patch to test tomorrow (home now..).
> > > > 
> > > > Well, I guess that depends on the semantics of Creator Owner with the
> > > > inherited bit set, doesn't it? Does Windows mark the new ACE created
> > > > as a result of a Creator Owner ace that has the inherited bit set as
> > > > inherited as well?
> > > 
> > > Yep (been testing against Win7). Windows marks *all*
> > > ACE's it creates as part of the inheritance code path
> > > with the SEC_ACE_FLAG_INHERITED_ACE bit.
> > > 
> > > It doesn't matter what the original inherited bit was.
> > 
> > And here's a COMPLETELY UNTESTED :-) patch.
> > 
> > Compiles, but that's all I can say right now..
> > 
> > I'll test when I get into work on my test environment
> > tomorrow.
> 
> It's tested now :-). Works perfectly (i.e. I reproduced the
> original reported bug, and the attached patch fixes it).
> 
> I'll push this to master, and raise a bug for 3.5.x and 3.6.x.
> 
> The nice thing about this is it's not associated with mapping
> into POSIX ACLs at all, it's simply a missing bit in the reported
> ACE entries (the fact that when re-ordering the Windows client
> added a duplicate entry but with the "SEC_ACE_FLAG_INHERITED_ACE"
> bit set was the give-away) so it'll be easy to add a RAW-ACLS
> testcase for it.

Hmmm. Not quite so simple as it looks :-). Causes us to fail
the raw.acls test. I'll investigate some more, but I'm
definitely on the right track.