[ On Sunday, June 17, 2001 at 21:43:32 (-0400), Rick Byers wrote: ]
> Subject: Re: Exim allways runs as root
>
> I agree with you, I was wondering what the motivation was for temporarily
> giving up root priveledges.  However, if configured for a non-root user,
> Exim will PERMANANTLY give up root priveledges when receiving a message.

Yes, I'm aware of that (and assuming of course that the OS really does
force the process to permanently give up its privs -- sometimes that can
only be done through exec).

> Of course then it has to invoke a new exim process to actually deliver the
> message since it no longer has permission to do so.

Indeed -- another setuid process so that it can "regain" its
privileges.

>  I'm not sure if any
> significant amount of code runs permanantly without root, but incase it
> does - I'll continue using "security=setuid'.  I just hope the authors of
> Exim have been really carefull about security.

Exim's author has indeed been quite careful about security -- perhaps
even more careful then Smail's past authors (though with well earned
hindsight -- he was one of them ;-) [and hopefully I've cleaned up most
past indiscretions].  I don't think he (Philip Hazel) completely grasped
the dangers of not always being able to give up root privs until
recently, but I think he does now.  I'm not sure in which release this
change was made, but I seem to remember the announcement appearing very
recently.  Given the recent reports on BUGTRAQ only the most recent
release is likely to be safe in some configurations too...

I don't know that even smail properly and permanently divests itself of
all its privileges when doing local delivery, but I think it does the
best any program can do without re-execing (a non-setuid version of) itself.

After recent discussions on BUGTRAQ I'm fairly committed to actually
eventually implementing changes I've discussed for Smail so that the
main process never runs as root.  Here's a short, and possibly
incomplete summary of what will change:  the daemon will setuid(nobody)
and re-exec itself after it has a file descriptor already bound to port
25; the main smail/sendmail binary will be setgid-smail (not "mail") so
that it can write to the queues; local delivery to spool files will be
done by a separate setgid-mail agent ala mail.local; initial spool file
creation will be done by a tiny setuid-root helper on systems that have
a root-only chown(2); all mail readers will be expected to either use a
small helper to safely copy the spool file to a private place (ala
movemail, which will use kernel file locking when possible or be
setgid-mail and use *.lock files if necessary), or to use kernel file
locking to access the spool file; and .forward files (which don't have
to be in $HOME) will have to be world readable with delivery to files
and pipes done as nobody:mail (by the separate local delivery agent, of
course).

> By the way, I was going to just upgrade IAW to the latest Smail but
> noticed that even the Smail README said "you should upgrade to something
> newer like Exim".  Do you and the rest of Planix prefer something other
> than Smail for your customers now then, and if so - what?

Well, I'd personally still never recommend Exim over Smail, but I do
recommend Postfix over most anything else these days.  (I think Exim is
too configurable, and though it's not as difficult to configure as
sendmail, the resulting complexity is rarely beneficial, and its
defaults are not always ideal for minimal installs.)

I just don't use Postfix for everything yet because it's still missing
some fundamental functionality that only Smail (and maybe Exim or
Sendmail) can offer.  I think Smail's also even easier to configure than
Postfix in basic scenarios, expecially for various SMTP restrictions.
Postfix often leans a little too far the Exim-way and tries to provide a
knob for everyone's needs, but at least it avoids the "I can do
anything" baroque state machine of sendmail.

(BTW, please apologise to Frank for my lack of reply regarding Smail --
I've been working on the 3.2.0.113, which is what he was told he should
request, but it does not yet exist!  ;-)  .112 is pretty good as such
things go though -- only a couple of minor bugs have been reported, and
so far the only enhancement in the works is better SMTP error reply rate
limiting.)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>