Permissions incorrectly ordered on Windows after disabling inheritance

[Jeremy Allison]

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.

Cheers,

	Jeremy.