[ On Wednesday, December 19, 2001 at 14:24:45 (+0000), Philip Hazel wrote: ]
> Subject: Re: [Exim] Exim and IBM DB2
>
> No, it cannot be avoided. Most delivery processes *are* exec{}'d,
> precisely in order to obtain privilege. The delivery process needs
> privilege so that it can run sub-processes which each become the
> relevant user for local delivery.
Oh, bugger -- of course not. I should have known that. In a reply
I made just moments ago, but which is currently stuck in the moderator's
queue because I forgot to adjust my from address, I suggested
otherwise. This message should appear on the list first, and if the
moderator forwards my waiting message, please ignore it.
> This can only be avoided if you are running in a restricted environment
> where either no local deliveries are done, or they are all done as the
> exim user, and you don't want .forward file support. As documented in
> section 46.2 in the Exim 4 manual, "Running Exim without privilege".
There are indeed other ways to avoid running as root, even if you do
local deliveries and with (limited) .forward file support (or if spool
file "Forward to" support is used).
I've written up a set of rules that I hope to implement in Smail some
day. They will make it possible to never run at least the main body of
the mailer code as root:
+ the daemon will setuid(nobody:smail) and re-exec itself after it
has a file descriptor already bound to port 25 (it will have to be
started by root on most systems, of course)
+ the queues will be writable by the group 'smail' (not "mail") and
owned (and also writable) by the user 'smail'.
+ the main smail/sendmail binary will be setgid-smail (not "mail") so
that it can write to the queues (and owned by root, of course).
+ checkerr will be run as smail:smail
+ local delivery to spool files will be done only by a separate
setgid-mail agent ala *BSD mail.local, with kernel locking where
possible, *.lock files only where absolutely necessary.
+ initial local spool file creation, if necessary, will be done by a
tiny setuid-root helper on systems that have a root-only chown(2)
[one exists somewhere already -- search the net]; they will be owned
by the user, group 'mail', and be mode 660. The spool directory
will be mode 555 if kernel locking is possible, else 575 & group
'mail' if necessary for *.lock files (and in all cases owned by
root, of course). the helper will _only_ create an empty spool file
if one does not already exist, and it will determine the pathname to
use based on the user name given to it on its command line.
+ 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 hopefully copy it away to a private place while
th user does his/her thing); mail readers (including movemail) will
be "encouraged" to keep the zero-length spool file after emptying
it; and use of setgid-mail for readers will be very Very VERY
strongly warned against (anything more complex than the old V7
/bin/mail has had many bugs in this regard for decades now).
+ .forward files will have to be world readable (or at least readable
by the group 'smail'), *or* "Forward to" support can be used.
+ delivery to files and pipes done only as nobody:mail (courtesy the
setgid-mail local delivery agent) regardless of where they're
expanded from or who "owns" the address. Anyone wanting more will
be advised to deliver to an intermediate lock-protected spool and to
run a collector daemon/periodic-job as with the ultimately desired
identity, though nothing will prevent the delivery to a pipe from
execing a setuid binary.
+ access to locked files will only be attempted for a limited amount
of time and messages will be left in the queue if delivery is
unsuccessful because of the presense of any pre-existing a lock
I may even forget the *.lock stuff since I know of no machine running
any mailer any more that doesn't have at least some form of basic
kernel-based advisor file locking.
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
