Samba under Coherant and Macintosh

[Andrew Tridgell]

I've moved this discussion to samba-techinical (we were making the
mistake again of having technical discussions on the private team
list)

for those who don't know Luke and I are in a long debate on a proposed
architecture change to Samba where things get far more split up into
separate daemons etc. Its a friendly but "robust" discussion :)


> > I think you misunderstand me. I propose that the rpc daemon run as
> > root all the time. I don't see any reason for it running as any other
> > user. The only possible exception is the spoolss stuff, which needs to
> > be able to run as a user in order to run lp* commands. 
> 
> i don't mis-understand you, i don't want to do it.
>  
> > we gain nothing but complexity by running the msrpcd as non-root.
> 
> we gain nothing but insecurity and the need to run unnecessary security
> checks by running as root.  like i think i mentioned earlier, i don't
> expect smbd to run as root-only, and exactly the same reasons apply to not
> have msrpc services run as root-only.

nope. The same reasons do _not_ apply.

smbd runs as non-root because it needs to do file access. File access
should be controlled by the OS, not by daemons as otherwise you end up
replicating the OS access control code in the daemon (and end up with
horrible race conditions).

As I've mentioned several times, the msrpcd does not need to do user
file access. With the exception of spoolssd it only ever accesses
internal data structures. Internal data structures are NOT protected
by your euid/uid. So jumping through the hoops of running as non-root
just gives you a false sense of security - it gains you no real
security.

> example.  svcctld i've just added a "start / stop service": it uses smbrun
> and the security context of the svcctld daemon.  you want anonymous users
> to be able to start and stop root daemons?

smbd should _never_ be starting/stopping daemons via rpc calls. I know
you have had plans in the past to do this and even ideas of making
everything in /etc/rc.d/init.d/ available as rpc services - I think
the whole idea is totally gross (as I said at the time). It is
features for features sake. Have you actually ever had a Unix admin
say to you "gee, I wish I could start/stop sendmail on unix via my NT
workstations domain management GUI" ?

even if such a feature were ever added (and it would be over my dead
body!) then it would only make sense to start/stop those daemons as
root!

if you have ideas of allowing users to start/stop their own daemons
via msrpc then that is just totally crazy!

> > the agents require two way comms to do their job. The packet-storage
> > idea requires one-way comms. That is the basic difference.
> > 
> > it also means that nmblookup (which runs unprivileged as a user)
> > cannot in any way break nmbd when receiving those broken to-137-only
> > replies, whereas with an agent it could impact on nmbd.
> 
> in what way?  what makes you think so?  agent-clients connect with a
> nmb-transaction-id.  we strip that out and replace it with our own
> (incrementing, unique) trn-id, recording the old nmb-trn-id.  when packets
> are received with our replaced-trn-id, we use that to match it with the
> agent-client, replace the old trn-id in the response and send it back up
> the pipe to the client.

heck Luke, just read through the above:

1) "agent-clients connect with a nmb-transaction-id"

so we now have nmblookup connecting via a special protocol to
nmb-agent. That opens up the possibility of something going wrong. It
is a protocol and interaction between unprivileged and privileged code
were none was before and none is needed. nmb-agent will need paranoid
code to check for invalid requests, overflows, go-slow-attacks etc
where right now we have _nothing_. 

with a storage area that is written only by nmbd and only read by
everyone else we absolutely guarantee that nmbd is never adversely
affected by any of these other programs. _absolutely
guaranteed_. Understand?? 

As soon as you have two way comms you don't have that guarantee. Don't
give up absolute guarantees when you don't have to - they are rare
enough already.

> what, in the scheme wheree nmbd, winsd, nmblookup, name_status() being
> used inside smbd or any other program, are all nmb-agent clients, could
> one agent-client impact on another agent-client under these circumstances?

when two problems communicate with each other something can go
wrong. If we don't need that communication (and I have shown that we
don't) then we shouldn't have it!

> ah.  i got a reason.  let's say some administrators or some managers don't
> trust a third party service.  if it's dlopene'd or part of smbd, they're
> highly unlikely to let it disrupt "critical services".  if it's a separate
> program, they might consider it.

then they are foolish and need educating. The two are equivalent
security wise (think about how symbols are bound when you do a dlopen
and compare that with what happens with a separate protocol and a
daemon - they are equivalent!).

for those who don't know, when you dlopen() a .so the parent does NOT
inherit all the symbols in the .so. It merely gets access to symbols
in the .so via dlsym(). The dlsym() calls must be explicit - just like
the rpc calls you will need to talk to a remote daemon.

the only extra thing you can do with a dameon is run it as a different
uid. I can't see any reason why you would do that (particularly as it
is more likely to lower your security than raise it - think about what
you have to allow binding-wise to do it!).

Cheers, Tridge