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

[Luke Kenneth Casson Leighton]

On Tue, 8 Feb 2000, Nicolas Williams wrote:

> On Wed, Feb 09, 2000 at 06:54:35AM +1100, Luke Kenneth Casson Leighton wrote:
> > >    I'm now for it as Luke's LDAP/NIS/other name services argument is a
> > >    winning one. The /etc/shadow approach should still be supported and
> > >    used where no such cleartext protocols are in use.
> > 
> > the SYSKEY2 thing also means that private/smbpasswd can be made
> > world-readable.  sounds weird, neh?  WAIT - hear me out, before shooting
> > mouths and telling me it's a stupid idea.  i didn't say make the SYSKEY2
> > key world-reabalb, that _is_ a stupid idea.
> 
> No, what you're suggesting is silly. The SAM RPC daemon should always
> run as root, so there will be no need for those become_root()/
> unbecome_root() calls.
> 
> Trust me: the SAM RPC daemon should always run as root.

ah ha.  no it shouldn't.  no MSRPC daemon should ever run always as root.
why?

implement this as the msrpc loop-back mechanism, and it becomes clear.
cut out all the marshalling code (cli_*.c and srv_*.c) and replace it with
this:

uint32 samr_open_domain(....)
{
	return _samr_open_domain(0...)
}

then, if you link rpcclient together with this, it should still work as
_if_ you had the cli_*.c and srv_*.c marshalling code in there.

of course, the become_root() / unbecome_root() calls screw that up right
royally, unless you were _already_ running as root.

the consequences of "always run as root" are that client-side programs, in
order to work on loop-back with the above implementation of ncalrpc, must
_also_ be run as root or have the setuid bit set on the binary, whatever.

which means a TOTAL, and unnecessary, code security review, of all
client-side msrpc and msrpc-using programs.

not a happy prospect.  rpcclient is 40,000 lines, last count, if you
include cmd_*.c.  50,243 to be precise, and that's excluding libsmb/*.c
and lib/*.c.

> > is because private/smbpasswd is root-only readable.  yes, there appears to
> > only be a password in it, but there's not, it identifes which unix
> > accoutns are also samba accounts.
> 
> The SAM RPC daemon should always run as root.

andrew keeps telling me that _All_ the msrpc daemons should run as root,
because the only reason that smbd doesn't run as root is because of
file-create atomicity issues (in posix, you can't create a file as root
and then chown it to another user, atomically, which introduces race
conditions).

well, the same reasons apply.  any msrpc daemon that creates files
(spoolss being the only one at the moment) or spawns programs (spoolss and
svcctl being the only ones... IF you damn well choose to RUN svcctl. WHICH
you don't have to] should also not be run as root.


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.

> > well, actually, we realy need to work out _microsoft's_ syskey2 for their
> > password ldap fields.
> 
> Fine, then your SYSKEY idea becomes really low-priority ;)

yes, i won't need it, i'll use ms's approach instead...

if it's any good!

> Sure. This particular case is an issue of compatibility with Windows
> 2000: supporting the use of Samba DCs as part of an ActiveDirectory
> system (strange, eh? but doable).

yep!
 
> Yes, finish (2) and (3) and merge in the rest of smbd from 2.0.x + (1)
> into TNG and you've got a TNG that is production quality for file
> serving and still a bit alpha for domain serving but getting there.

yep
 
> > i think that's all.  if someone wants to take each of these things,
> > starting in that order, there'd be lots of grateful people around.  oh and
> > you'd be entitled to a samba team t-shirt, of course.
> 
> ah, uh, well, ah, I'm busy (scurries off).

:)