On Thu, 20 Dec 2001, Miquel van Smoorenburg wrote:
> You have less code. The daemon doesn't need to be setuid root at all.
> That is always good. I know I've had thinkos and buffer overflows in
> some of my programs in parts I never even expected. Nobody's perfect.
Agreed. bit the little bit of privileged code at daemon start up doesn't
have to be very large.
> Also, it makes it possible to close and re-open priviliged ports.
That is a relevant point.
> But indeed this doesn't fit the exim model right now if you also
> have local deliveries, since exim needs to setuid() to the user
> at that point, so it needs to be setuid root anyway.
That's true - because Exim has only one binary. If there were separate
binaries for the daemon and for other operations, some could be setuid
and some not.
> And you're
> probably not looking at making exim a second postfix.
I've said that many times! I do not want or intend to change the Exim
design in this regard.
> True, somebody should write a generic daemon that does this that
> has a config file in which you can define what users can bind to
> what ports. That way it can be used by apache, inn, exim, etc
> but it will probably never happen :|
A generic daemon must also cater for binding to specific interfaces, and
binding using IPv4 and IPv6 functions, so its interface would have to be
a little more complicated that just a port number. There is also the
matter of retrying (or not) if the binding fails because the port is
held by another process.
> Anyway, it was just something that I though was a neat idea-
> it's certainly original. Would you have thought of it ? :)
No, I would never have thought of it, because it would never have
occurred to me that a binding done by a subprocess would affect the
socket in the parent process. I continue to learn new things about the
way Unix works.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
