Re: [exim-dev] What user should ${run...} in config file run…

Top Page
Delete this message
Reply to this message
Author: Philip Hazel
Date:  
To: Jethro R Binks, David Woodhouse
CC: exim-dev, Graeme Fowler
Subject: Re: [exim-dev] What user should ${run...} in config file run as?
On Mon, 13 Dec 2010, Jethro R Binks wrote:

> I'm sure Philip has passed commentary on this situation in the past.


I probably have. When I first started to write Exim, I did try to design
it as a number of separate binaries, but the problem that made me change
my mind was the difficulty of passing information between them. Also, I
realized that the "receive message" code needed to have the "deliver
message" code available (or quite a lot of it) so that it could apply
recipient checks at SMTP time. So having it all in one binary made
sense.

(Another issue that I thought about was "how do you update a *set* of
binaries instantly?" but of course that is easily solved by sticking
them all in one directory and updating a symbolic link to the
directory.)

Having said that, I readily confess that I was probably too naive about
security issues at that time, not having had very much experience. There
is evidence for that in the way things changed between Exim 0.00 and
later releases, as I learned more (e.g. don't use seteuid()). Also, I
knew only the basics about processes, pipes, shared memory, etc., that
is, stuff that could help with passing information around. (Until 1990 I
had been an IBM mainframe person.) Copying what Smail (and indeed
Sendmail) did rather than trying to be innovative (and perhaps screwing
up spectacularly) seemed a safer bet.

On Mon, 13 Dec 2010, David Woodhouse wrote:

> It would be an interesting exercise to see how much we could reduce what
> Exim does as root when setting up for a delivery run. If we could get to
> the point where it doesn't need to interpret the config at all, but is
> handed everything it needs for that specific delivery 'on a plate', then
> that might be interesting. Although of course if you pass it information
> by some other means you still have the question of why it should *trust*
> what it's being told...


That's basically what I couldn't see how to do (see my 1st para above).

While I'm here... I must say, I've been impressed by the way people have
leapt in and worked on the security issue in the last week. Nice work!

Philip

--
Philip Hazel