>> On the other hand, if exim is run from inetd (as I do), does it
>> still need to be suid root? Since inetd runs root anyway, there should
> well this is not a problem. (x)inet works by using stdin/stdout rather than
> network ports. This is why you have to tell whatever service you are
> superserving its being run from (x)inet. Hence you do not need to have root
> privilages as no ports are being opened, even if they were there would be an
> error as the os says "sorry port already claimed" or words to that effect.
Please quote only the relevant part of the message you reply to. I
do not know which part of my message you replied to since you quoted
it all.
There was only one question, though and I left that double quoted.
Assuming you replied to this part, what do you mean by it being no
problem? Exim running as root is no problem? Of course it is if it is
not necessary to run! Programs should never (or at least as
infrequently as possible) have extra priviledges. And even though
inetd may be invulnerable to some exploit, exim may still be. Running
exim from inetd does not prevent exploits from being exploited. The
only things I can see we gain from using inetd are 1) there is only
one daemon running (less memory consumed) and 2) only inetd _needs_
setuid root. If the communication between exim and inetd works fine
without exim being suid root, then it should be possible to remove the
bit from exim. Now my original question was: does it (exim) still need
to be suid root? And the question still remains and depends (solely?)
on whether it still can communicate with inetd. Inetd runs exim with
mail's priviledges so giving mail access to any necessary directories
is enough for exim to function - unless there are issues with the
permissions of /var/spool/mail/<insert your favourite username here>.
Now another question: are there?
--
-----------------------------------------------
| Juha Jäykkä, [EMAIL PROTECTED] |
| home: http://www.utu.fi/~juolja/ |
-----------------------------------------------
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
