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

[Nicolas Williams]

BTW, I knew that you'd respond as below. :)

On Wed, Feb 09, 2000 at 07:32:11AM +1100, Luke Kenneth Casson Leighton wrote:
> On Tue, 8 Feb 2000, Nicolas Williams wrote:
> > 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.

Wait a minute. The goal, ultimately, is to have ONE set of MSRPC daemons
for ALL smbds on a host, not what you have now (ONE set of MSRPC daemons
for EACH smbd on a host).

Once you get to your stated destination you'll not have to worry about
how to start those MSRPC daemons: /etc/init.d/ scripts will take care of
that.

As for the way TNG does this now, with each smbd fork()/exec()ing the
MSRPC daemons as necessary, smbd should become_root() before starting
them.

As for rpcclient it should ALWAYS do DCE/RPC calls via SMB, even when
running on the host that would be servicing those calls. So forget about
linking in server-side code into rpcclient. So that's a non-issue.

> > > 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).

He's right about why SMBD needs to do become_root()/unbecome_root().

SMBD exports a filesystem and so can make use of POSIX features
(uid/euig/gid/egid/getgroups()/setgroups()) to let the Unix kernel do as
much of the work of authorization as possible.

MSRPC daemons export a set of functions and whether or not each daemon
can take advantage of POSIX semantics to implement any part of the MSRPC
authorization semantics is an issue that is specific to the
implementation of each MSRPC daemon. See below.

> 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.

And you're right that it is conceivable that some MSRPC daemons should
change privileges as well. [BTW, Unix spoolers never run as the user
that launched each job. Nor does ypserv ever switch to the calling
user's uid/gid. I could go on.]

But the LSA, SAM and NETLOGON RPC daemons should not.

> 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.

LSA simply does SAM/NETLOGON calls on behalf of the client -- the
client's POSIX uid has no impact on this.

Similarly with NETLOGON.

SAM accesses a database the same way no matter who is making the SAM
calls (I mean at the system call level). SAM will need to do
authorization internally; no Unix authorization mechanism will change
this (unless you use a filesystem as a database -- as opposed to TDB or
LDAP -- but that has its problems and is a non-starter, I bet).

Andrew is right.

> 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.

[...]

> > 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

There's the merge strategy.

> > > 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).
> 
> :)

:)

Nico
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.