LSA Privileges

[Simo Sorce]

On Sun, 2003-02-09 at 11:52, Simo Sorce wrote:

> Yes, that what I , and before me Jean Francois, tought about that.
> 
> Furthermore I think the while it is certainly a possibility that MS
> programmers made the transfer by string as a mistake, in realty I think
> it has been on purpose, so that they could add new priveleges easily if
> needed.

Replying to myself lokking at the trace again I see that user's
privileges are passed always as strings not numbers. It may really be
that they always use strings not numbers.

So s/string-number pair/string/

>  I think our best bet could be to keep the string-number pair we
> receive from a PDC intact and associate to this pair a second number
> internal to samba. An interface that is able to map samba internal
> privilege number to windows string-number pair one should be provided so
> that if we discover new privilege names besides the ones we already know
> we can easily map them to a samba own privilege if needed (or map a
> known unused one to a samba one so that admins can manipulate it easily
> through windows interfaces).
> 
> > Finally, we will need an admin interface for privileges. The two
> > possible ways to do this are a local 'net privilege' command that
> > manipulates directly via pdb, or a remote command like 'net rpc
> > privilege' that manipulates via MSRPC. The advantage of 'net rpc
> > privilege' is that it will work against remote servers. The advantage
> > of a local command is that it will work when smbd is not running. Or
> > maybe we should have 'net rpc privilege' and a local edit via pdbedit?
> 
> Yes, it seem the best solution.

Simo

-- 
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20030209/a4219ff1/attachment.bin