I believe I have found the reason for "The permissions on blah are incorrectly ordered ..."
Richard Sharpe
realrichardsharpe at gmail.com
Tue Apr 2 07:43:21 MDT 2013
On Tue, Apr 2, 2013 at 2:23 AM, Andreas Schneider <asn at samba.org> wrote:
> On Wednesday 27 March 2013 14:50:15 Jeremy Allison wrote:
>> On Wed, Mar 27, 2013 at 02:35:42PM -0700, Richard Sharpe wrote:
>> > This appears to be the fix:
>> >
>> > --- samba-3.6.12/source3/lib/secdesc.c.orig 2013-01-29
>> > 00:49:31.000000000 -0800
>> > +++ samba-3.6.12/source3/lib/secdesc.c 2013-03-27 21:25:35.978421867
>> > -0700
>> > @@ -592,7 +592,7 @@ NTSTATUS se_create_child_secdesc(TALLOC_
>> >
>> > struct security_ace *new_ace =
>> > &new_ace_list[new_ace_list_ndx];
>> > const struct dom_sid *ptrustee = &ace->trustee;
>> > const struct dom_sid *creator = NULL;
>> >
>> > - uint8 new_flags = ace->flags;
>> > + uint8 new_flags = ace->flags &
>> > ~SEC_ACE_FLAG_INHERITED_ACE;
>> >
>> > if (!is_inheritable_ace(ace, container)) {
>> >
>> > continue;
>> >
>> > We are trying to OR in the INHERITED flag depending on the flag in the
>> > type/control field on the parent SD, but are forgetting that it might
>> > already be in the flags on the ACE we are dealing with. So, we have to
>> > get rid of it first.
>>
>> Actually I think this is the more correct place to do it (see attached).
>> It's in the place we're already modifying new_flags anyway.
>
> If we have a mail thread about a bit, maybe it makes sense to also add a
> comment to the code why we remove it? :)
Yes, it does. Let me prepare a patch to do that now.
--
Regards,
Richard Sharpe
(何以解憂?唯有杜康。--曹操)
More information about the samba-technical
mailing list