On Thu, 8 Mar 2001, Nigel Metheringham wrote:
> The code for the accept and multiple reuse of an incoming socket from
> inetd can be found in the pidentd code. Modifying exim for this mode
> would be a relatively trivial operation.
1. I've made a note to think about this for Exim 4.
2. Those who advocate setting up the Exim binary so that it is not
setuid=root for security purposes should, however, consider the subtle
side effect.
. If exim IS setuid=root, then when it starts up, it is running with
euid=root and uid=caller. It obeys setuid(root), which makes both uid
and euid root, and discards any privilege that the calling uid might
have had (in systems with ACLs and so on, non-root uids may have some
privileges). It also discards any additional groups that are set up.
If, in addition to being setuid=root, it also has security=unprivileged
set, it then obeys setuid(exim) -- after binding to port 25 when starting
the daemon, or otherwise immediately -- so that it ends up with
uid=euid=exim, gid=egid=exim and no additional groups set. That is, it is
totally divorced from the calling process' uid and groups.
. If exim is NOT setuid=root, it cannot do this. If, for example, it
is setuid=exim, then it runs with euid=exim, but the uid remains as
that of the calling process.
3. In Exim 4, this will be essentially the same, except that I'm
removing all uses of seteuid() from the program. The "security" option
will no longer exist because there's no choice, but the equivalent of
"security=unprivileged" will be available by an option called
"deliver_drop_privilege", which will cause Exim to drop its privilege
when delivering a message. In all other cases (starting daemon, listing
queue, etc. it already drops privilege automatically).
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
