Graeme Fowler wrote: > On Mon, 2010-12-13 at 10:15 +0000, David Woodhouse wrote: >> It will drop privs when run as a dæmon, and it *cannot* get them back. > > That's what I was expecting. > >> It doesn't work like that. You cannot *gain* root privs; you can only >> give them away if your process was started with them. >> >> So what it does is fork and exec a *new* Exim process to do the >> delivery. That version of Exim doesn't drop privs. > > Aha, now my poor little dumb brain understands: the "missing link", as > it stands, is the setuid bit on the Exim binary.
Removed (here). No harm (here). > > Now... again, poor little dumb brain time again: Why do we need Exim to > be setuid root? Presumably this is so it can change user when invoked to > do local deliveries as the right user (amongst myriad other things). > Perhaps an 'edge case' - and bigtime, but *here* we don't ask Exim to deliver messages to UID:GID other than its own. All of our users are virtual, ergo HAVE NO system UID:GID. CAVEAT1: Needs care in how the POP/IMAP service runs as well. MUCH care. CAVEAT2: This is only the most obvious, and perhaps most widely-depended upon thing that would change. MANY folks DO allow shell-account holders to (also) have mail under the same UID:GID. As easy as it is to use virtual instead (AND decouple shell login-ID and email ID to better secure BOTH), that still will not change. There will be other reasons. > To cut to the chase (I hope I'm not really as dumb as I make out): are > we looking at a significant architectural change here, really? It > strikes me that having a single binary responsible for everything is a > bit of a limiting factor in terms of risk management, especially given > the setuid nature of the installation. We are in F/LOSS -land. Have a look at Sam Varshavchik's rationale as to why courier-mta is so 'modular'. > If we separated out the local > delivery process (for example) to be a binary in and of itself then the > potential for exploitation is reduced. > True. And less convenient w/r config, flexibility, and doing the odd stuff. Courier-mta sticks more closely to smtp, stricter RFC compliance, and NOT being a toolset to gratuitously enable disregarding whatever-the-Hell the admin chooses to do differently. Which, for better or worse, is what many of us *want*. Exim makes it easier, so .... > Yes, I know that's no small undertaking. > > Graeme > Not hard. Just tedious. EITHER Exim OR courier-mta can be made to onpass to a DBMail back-end mailstore, for example. BTDTGTTS. The 'why' of it that is a different saga.... Think 'former SQL addict'. And 'not recommended'. ;-) Bill > > -- ## List details at http://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
