lsa policy handle

[Jean Francois Micouleau]

On Thu, 29 Nov 2001, Tim Potter wrote:

> Yes.  The discussion on tng had something to do with different objects
> having different permissions on them so you could achieve finer
> grained access to resources on a NT system.  I'm not sure how this
> usefully translates to Samba.  I guess if it was necessary for
> basic interoperability then someone would have coded it up by now.

Up until now we didn't have a need to check the desired_access and who was
the user doing the open_policy(). As all the lsa functions we had were
only 'read' functions.

since I have added some 'write' functions, we now need to check.
Tim, that's like the spoolss_open_printer() call.

The problem I have is simple: basically on NT you have an SD (or a DACL
doesn't make a difference) attached to the LSA process. The DACL contains:
- (WORLD, GENERIC_EXECUTE)
- (SYSTEM, POLICY_ALL_ACCESS)
- (admins alias, GENERIC_FULL)

and you can't change that DACL, it's hardcoded somewhere (or maybe stored
in the registry doesn't matter).

As on samba we don't have nested groups, and as I don't want to add yet
another "lsa admin" param to smb.conf, that would be not fine grained
enough, I'm stuck with adding either 3 or around 25 privileges to the
group mapping code.

3 is GENERIC_ EXECUTE|READ|WRITE and we can emulate correctly an NT box.
GENERIC_EXECUTE is used in the Lsa Enum functions
GENERIC_READ is used in the Lsa Query functions
GENERIC_WRITE is used in the Lsa Set functions

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 !

and now the fun is: I can replace LSA by SAM and duplicate this long and
boring message.


	J.F.