[ On Thursday, December 20, 2001 at 07:35:37 (+0000), list-exim-users@??? (Miquel van Smoorenburg ) wrote: ]
> Subject: [Exim] Re: Exim and IBM DB2
>
> In article <20011219214911.E5868B5@???>,
> Greg A. Woods <woods@???> wrote:
> > + 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)
>
> On the INN mailinglist someone suggested the following:
>
> - let the non-priviliged daemon create a socket and fork()
> - the child exec()s a small setuid helper program
> - that setuid helper program ofcourse also inherits the socket fd
> - the helper binds the socket to port 25 and exit()s
>
> Now the main program has a socket bound to port 25..
Yes, that will usually work (except maybe on types types of systems
smail (and exim) have not been ported to....
However that would only be necessary on broken systems which don't allow
a process to as easily give up its privileges.
Root is likely going to be starting the SMTP daemon on most systems
anyway (though on NetBSD, for example, there's built-in support for
starting daemons with "su -m $daemon_user -c '/path/to/daemon'").
I.e. you have to be prepared to explicitly and permanently give up
privileges in the process that will be the SMTP daemon anyway. One may
as well just take advantage of those privileges to bind to the reserved
port. The additional few lines of code that have to be run as root are
going to have to be in some program somewhere so I think it's best to
reduce complexity as much as possible and have all the root-run code in
one place.
(There is one minor glitch caused by having a set-id-non-root binary run
by root on some systems. The coding workaround is non-intuitive and has
triped up many a set-id programmer in the past. The easy work-around is
to have a root-owned non-set-id binary in some private place for root to
use to start the daemon, but that's not an ideal solution, obviously.
In this case though if the binary is only setgid, and not setuid, the
coding workaround is not so tricky.)
> If you want the users to be able to mount the spool over NFS
> you *have* to use dotlocking. And you have to do it "right"
> (like exim does it, using link(2)).
Well, actually I've never advocated spool delivery (or pickup) over NFS,
and now that there are protocols like LMTP for delivery to client
machines, and central mail storage and access systems like Cyrus-IMAPd,
etc., I don't mind actively discouraging delivery over NFS either! :-)
--
Greg A. Woods
+1 416 218-0098; <gwoods@???>; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
