[PATCH] Merging the privilege code

[Andrew Bartlett]

On Tue, 2010-08-31 at 07:49 +0200, Volker Lendecke wrote:
> On Tue, Aug 31, 2010 at 12:31:27PM +1000, Andrew Bartlett wrote:
> > As to why I feel the SE_PRIV bitmap is not suitable for use in an IDL
> > defined structure, our IDL does not as far as I know provide an easy way
> > to generate defines such as:
> > 
> > #define SE_NETWORK_LOGON               { { 0x00000001, 0x00000000,
> > 0x00000000, 0x00000000 } }
> 
> Couldn't we add something to PIDL that does this? It could
> even find the number of bits required and make the structure
> allocate the require number of uint32's or even make it an
> array of uint8's.

Volker,

We certainly could, but it wouldn't be a good idea.  If it were to
dynamically determine the size of the bitmap, it would be useless for
the construction of interoperable IDL, because if it were to generate a
scaler, adding a new flag could change the size of the structure.  

If we didn't want it to be a scaler, then we can already do:

uint32_t num_bits
[size_is(num_bits) uint8_t *bits[]

It would waste a little memory, and require allocation, but it could
work.

However, as we have already agreed:
> it is very
> unlikely that we will ever have more than 64 privileges

I would suggest that the correct way to represent an IDL defined bitmap
of less than 64 bits is as a [bitmap64bit], generating a uint64_t.  If
database formats are your concern, I'm more than happy to write a second
(0) 64 bits into the account_policy.tdb to make up the 128 bits we
currently use there, and to rework the small amount of code that
continues to reference the bitmap directly if we ever have more than 64
privileges.

We could also look at the full list of privileges that Samba4 currently
defines, and decide if we want to actually claim to support and allocate
bits to them all (Samba3 still only enumerates the 8 privileges it did
in the past).

While we certainly could expand PIDL to support constructs that are only
used between Samba instances sharing exactly the same IDL input, I would
suggest we save such complexity for problems without as simple an
alternative solution. 

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/20100901/02b81f5b/attachment.pgp>