Samba under Coherant and Macintosh

Luke Kenneth Casson Leighton lkcl at
Fri Dec 17 18:49:50 GMT 1999

On Fri, 17 Dec 1999, Andrew Tridgell wrote:

> > you're looking for reasons not to support nmb-agent, and those same
> > reasons apply to nmbd [invalid requests, overflows, go-slow-attacks],
> > therefore they don't apply.
> As I explained to Luke on the phone this morning, there is a critical
> difference - nmbd uses SOCK_DGRAM whereas nmb-agent uses
> SOCK_STREAM. By using SOCK_STREAM you open yourself up to lots of
> these nasties. and, in case you wonder, just changing it to SOCK_DGRAM
> doesn't solve all your problems, it just adds different ones.

i have a solution to this: it's to do one select plus a
read-at-zero-timeout of 4 bytes in which the length of the data is stored,
then another read-at-zero-timeout of that length, and if the data doesn't
arrive instantly, or is short, go back into the select loop.  on receipt
of all the expected data, _Then_ you process the packet.

it means storing state on a per-file descriptor basis.
> also, nmbd has a pile of code to be paranoid about the format of
> packets. It carefully checks packets to make sure they are
> valid. nmb-agent doesn't do that.

hmm, i missed those bits, i'll take a look.
> I think I've finally convinced Luke to drop nmb-agent.

by basically describing that the effort to be expended is solely on
reworking something that already does a good enough job (nmbd).

so i leave the _use_ of nmb-agent for another day, when i have blue-sky
time available.

i still need vagent.c (which is used in other places) to work reliably,

> The next step
> is for me to get moving on the database stuff so we have something to
> replace it with.
> > andrew, you just don't get it.
> > 
> > do you really, really want an anomymous user to run an msprc service as
> > root?  the answer, is a most definite, absolute no way.
> I do get it Luke. I hope my conversation with you this morning
> clarified things for you. If not then I'm pretty close to giving up
> with explaining it. 
> Your reason for running it as non-root is so you can launch new
> services as an anonymous user. I won't allow that anyway - we are not
> going to have Samba turn into a rexec replacement. "magic script" was
> a mistake that I've regretted, I'm not going to repeat it.
> The only other reason you seem to have is some mythical deep-seated
> notion that things run as non-root are magically secure. They
> aren't. 

[andrew explained that smbd does file operations as the-user because there
is no other way to do atomic operations such as
this can only be done without generating race conditions as the user].

*oh* - there is one slight problem that we have to work-around if not
doing a become_user(), andrew: that's that reload_services() currently
relies on you being the current user context.

there's a fudge in the NETLOGON pipe: see pstring samlogon_user.  we'd
need to do something more comprehensive and very similar.
> > i just can't bring myself to not put in become_user() calls.  i really
> > can't.
> get over it. Doing become_user() calls in this case will _lower_ our
> security. 

then this needs to be fixed in 2.0.X before it's released.  oops, it's
already out.

> It is a common security misconception that running as non-root is
> always better - it is only better in some cases and this isn't one of
> them. I particularly want you to code this for running as root as it
> will hopefully make you more paranoid when writing the code. Your
> conviction that running as root is dangerous can be turned into an
> advantage that way.
> > why is it that you think that msrpc services don't need to do file access?
> > what about access to private/smbpasswd from samrd?
> we do become_root() before those anyway, so thats totally
> irrelevant. (the smbpasswd can _only_ be accessed as root).
> > do you want anonymous users to be able to read the SAM database,
> > just like NT allows?
> of course not, but doing become_user() won't stop that. It will just
> give you a false sense of security.

i do need to add an entire security model on a per-pipe, per-function and
per-info level basis.

i was hoping not to have to do this _quite_ just yet and to use a
simplified model, first.
> > i'm into expanding the possibilities, and at the moment it looks like
> > you're into closing them all because they sound, to you, really crazy.
> don't add features without good reasons. Keep the code simple. Don't
> use sham security measures that end up adding complexity and lowering
> real security. Above all, think of the maintainability of code before
> writing it.


More information about the samba-technical mailing list