Fix our privileges code to display privileges with the "high" 32-bit value set.

Andrew Bartlett abartlet at samba.org
Thu Nov 18 16:57:26 MST 2010


On Thu, 2010-11-18 at 14:53 -0800, Jeremy Allison wrote:
> On Fri, Nov 19, 2010 at 09:35:07AM +1100, Andrew Bartlett wrote:
> > On Thu, 2010-11-18 at 18:59 +0100, Jeremy Allison wrote:
> > > The branch, v3-6-test has been updated
> > >        via  7c9515c Fix our privileges code to display privileges with the "high" 32-bit value set.
> > >       from  886471d s3: Call sid_check_is_domain instead of dom_sid_equal
> > > 
> > > http://gitweb.samba.org/?p=samba.git;a=shortlog;h=v3-6-test
> > > 
> > > 
> > > - Log -----------------------------------------------------------------
> > > commit 7c9515cbe26364a5ecfe609f56ac0ee6b6115f67
> > > Author: Jeremy Allison <jra at samba.org>
> > > Date:   Thu Nov 18 09:58:38 2010 -0800
> > > 
> > >     Fix our privileges code to display privileges with the "high" 32-bit value set.
> > >     
> > >     SeSecurityPrivilege is the first LUID we have added that has a non-zero
> > >     "high" value, ensure our LUID code correctly supports it.
> > >     
> > >     Jeremy.
> > 
> > Jeremy,
> > 
> > I've just reviewed the privileges table in v3-6-test, and I can't see
> > how this is the case.   All the values, including SeSecurityPrivilege in
> > the privileges in table have only the low 32 bits set, and the same is
> > true for the privileges table I dumped from Windows (see
> > librpc/idl/security.idl)
> > 
> > Surely there must be something else going on here to prompt this patch?
> 
> This was a problem in the 3.5.x privileges code, which uses the high
> 32-bits for SeSecurityPrivilege. 

I can't even see SeSecurityPrivilege in v3-5-test.  Is it defined like
all the others, or has someone added it in another patch, with an
unexpected LUID value?

> I had to go on an OEM site to debug
> this yesterday and add this patch to enable "net rpc right list 'user'"
> to display the correct privileges list.
> 
> The 3.6.x code and master are not the same here, and looking at
> lib/privileges_basic.c in v3-6-test I saw SE_SECURITY has the
> same LUID definition as in 3.5.7, so decided to make the same
> fix to be sure.

Ahh, so someone copied in the line literally, without paying attention
to the other values in context, and so used the high bits, and not the
low bits?

> Now you've prompted me to look at the LUID definitions more
> closely, the "low" and "high" fields have changed order (great!:-)
> in the struct definition in v3-6-test from 3.5.x.
> 
> So yeah, you're strictly correct in that in v3-6-test we're
> back to not using 'high', but having just had to fix a bug
> where we did use it and the arbitrary check that "high must == 0"
> screwed us up I don't think it's too bad to remove that check.

That all makes sense, so it has the same definition as 3.6, rather than
following the pattern of the rest of the table.  What had me confused
was that I was expecting that all privileges would work, or no
privileges would work...

> > Also, the new common privileges code uses an enum covering only the low
> > 32 bits, because it was clear from extensive investigation that only the
> > low 32 bits are used.  (Aside from the fact that LUID values are meant
> > to be server-defined, and not valid across reboots).
> 
> We now have *3* different versions of this code - a different
> one in master, v3-6-test and 3.5.x, and I'm trying to keep them
> all working :-). It gets confusing....

Wow!  I can see why folks are talking about eliminating the current 3.6 branch and trying again...

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20101119/f63717cf/attachment.pgp>


More information about the samba-technical mailing list