SYSKEY, TNG freeze, 2.0.x->TNG merge and other thoughts

[Luke Kenneth Casson Leighton]

On 8 Feb 2000, Todd Sabin wrote:

> Luke Kenneth Casson Leighton <lkcl at samba.org> writes:
> 
> > 
> > basically, MSRPC is a remote function call mechanism.  if the caller is
> > root, the remote function call is root.  if the caller is a threaded
> > applcication, the remote function call is a threaded implementation.  if
> > the caller is user-foo, the remote function call is user-foo.
> > 
> > that's the way MSRPC is designed, that's its job, and to expect it to do
> > anything else (e.g run remotely as root) is, in my opinion, asking for
> > trouble.
> > 
> 
> No, that's not how MSRPC is designed.

you sure about that?

>  The server runs in whatever
> security context it starts up in.  If the call is authenticated, and
> if the client has permitted it, and if the server decides to do it,
> the server can impersonate the client for some part of the duration of
> the call.
> 
> On NT, lsass (the thing that implements samr and lsarpc) runs in the
> SYSTEM context, and does so most of the time, even when servicing an
> RPC.  It impersonates the client only briefly to validate that the
> client has the proper permissions to do what it's asking.

i am curious.  what happens inside LsaOpenPolicy().  the connection is
anonymous, yes.  the server is running as SYSTEM context.  is it the job
of the _lsaopenpolicy call_ to switch to the context of the cient
(impersonatenamedpipeclient), or is it the job of the _msrpc hanlder_ to
call impersonatenamedpipeclient?

logically, i would expect the msrpc handling code to switch the context to
that of the client, whereup the function call decides to switch it back
again because they need SYSTEM privileges.