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

[tridge at linuxcare.com]

> So the MSRPC daemons will have access to the user context information.
> They have to implement authorization functionality internally because
> the objects which most of those MSRPC daemons deal with are NOT Unix
> kernel objects (files, pipes, Unix sockets, processes, whatever); if
> those objects are not Unix kernel objects then switching Unix security
> contexts (euid/egid) HAS NO EFFECT.

I am so glad to see that somebody else understands this. It is a very
important concept.

We have to decouple the unix security context from the RPC security
context. We have the SMB and Unix security contexts coupled in smbd,
but we get away with that because we are dealing with objects that the
unix kernel knows about so the unix security handling does all the
work for us. In msrpcd the situation is quite different as we are
manipulating objects that have no parallel in the unix world - so we
must not couple the security contexts or we end up relying on
protection that the kernel just can't provide.

In NT things are different. There they have the objects in the kernel
and the kernel knows how to protect them. The NT kernel security
context provides protection of the objects manipulated by msrpc
calls so there is no issues as to whether these two contexts should be
coupled - they are the same thing. On non-NT systems we must design
things quite differently.

Think about the above couple of points carefully Luke. They are central
to what you are working on.

Cheers, Tridge

PS: I'm away for the next month - expect only occasional email
responses.