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

[Jeremy Allison]

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 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.

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.

> 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....

Jeremy.