In article <Pine.SOL.4.33.0112200930490.5037-100000@???>,
Philip Hazel <ph10@???> wrote:
>On Thu, 20 Dec 2001, Miquel van Smoorenburg wrote:
>> 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..
>
>How does this make life more secure than:
>
>- let the daemon program be privileged
>- the daemon creates a socket and binds it to port 25
>- the daemon obeys setuid() to give up the privilege
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.
Also, it makes it possible to close and re-open priviliged ports.
So if the infrastructure allows it, you don't need to re-exec your
main daemon just because you need to re-bind the socket (say after
a SIGHUP to reconfigure). But that is an added advantage.
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. And you're
probably not looking at making exim a second postfix.
>(which is what Exim does)? You also have the added complication of
>controlling who may exec the helper.
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 :|
Anyway, it was just something that I though was a neat idea-
it's certainly original. Would you have thought of it ? :)
Mike.
--
"Don't worry about what anybody else is going to do ... The best way to
predict the future is to invent it." -- Alan Kay.
