[PATCH] Merging the privilege code

[Andrew Bartlett]

On Fri, 2010-08-27 at 09:15 +0200, Volker Lendecke wrote:
> On Fri, Aug 27, 2010 at 08:49:26AM +0200, Volker Lendecke wrote:
> > Just so that it's not lost in irclog: I don't like making
> > the privilege mask a simple uint64_t. I know it is very
> > unlikely that we will ever have more than 64 privileges, but
> > in S3 we currently have an easily expandable struct. I would
> > not like to lose the clarity of the typedef. I would prefer
> > a "struct se_priv", because that is the Samba way to express
> > special designation of a data type. I don't mind changing
> > the current contents of that struct, but I don't feel well
> > with losing special type designation.
> 
> Another argument in favor of a struct: Type safety. We even
> have NTSTATUS (which really is just a uint32 even) as a
> struct, Tridge went through great pains to make it one, and
> this revealed quite a few bugs.

I've extended the patch series to address the expandability constraints
here - all the callers outside libcli/security/privileges.c and
source3/lib/privileges.c now only use an enum sec_privilage to query or
set the privileges of a user.  While C does not provide strict type
checking on enums, it is stronger protection than a typedef, fits with
your requirement for clarity of purpose and allows the values to be
resolved inside a debugger. 

As you say, it is highly unlikely that we will ever need more than 64
privileges, but if we do, any conversion back to a structure will only
need to be within those files, not across the broader codebase.  

I've also worked to remove the se_* accessor functions that were left
untouched in the previous patch, and the global variables that were
required to operate them.  I hope you will agree this leaves us with a
much clearer API. 

The revised branch has been uploaded to my session-info branch for
review.  It passes 'make test' with 4 failures that I'm still
investigating. 

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/20100830/69cca592/attachment.pgp>