lsa policy handle
mimir at spin.ict.pwr.wroc.pl
Thu Nov 29 08:16:02 GMT 2001
On Thu, 29 Nov 2001, Jean Francois Micouleau wrote:
> On Thu, 29 Nov 2001, Rafal Szczesniak wrote:
> > sounds like a new tdb ?
> > 'lsa admin' param is certainly not the best idea :)
> a new tdb is not required. The new group mapping code in HEAD has all the
> infrastructure to store privileges now. I need to work on the tdbsam user
> backend to add privileges to users too.
Could you point me out ? It'd save me searching through the source
code files ...
> the remaining are subset of this ones, or more exactly GENERIC_xxx are
> made from others bitmasks.
> You should find all the informations in the MSDN, do a search on "LSA" or
> "LsaOpenPolicy", should give you a starting point.
Not especially, but still searching ;-)
> > > Or we go the full fine grained way, and for each Lsa function we have a
> > > privilege. Btw that's what NT does, but you don't have access to it as you
> > > can't change the default DACL !
The question is then: how thoroughly do we want to simulate NT ?
> > sounds yet more like a new tdb ? On the other hand it yields further
> > degree of complexity of the code :(
> oh no not at all a degree of complexity.
> all I have to do is add something like:
> if(!se_check_privilege(p->current_user->token, MINIMUM_NECESSARY_PRIVILEGE))
> return NT_STATUS_NOT_ENOUGH_PRIVILEGE;
> at the beginning of each functions in srv_lsa_nt.c and srv_samr_nt.c
But desired access should also be associated with returned policy, to
allow smbd to return access denied if it happens.
|Rafal 'Mimir' Szczesniak <mimir at spin.ict.pwr.wroc.pl> |
|*BSD, Linux and Samba /
More information about the samba-technical