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