Re: [exim-dev] Pipe transport run by user?

Página Principal
Apagar esta mensagem
Responder a esta mensagem
Autor: Bryan Henderson
Data:  
Para: exim-dev
Assunto: Re: [exim-dev] Pipe transport run by user?
>I may be wrong, but from the way you have worded your question, I think
>you haven't quite understood the way Exim works.


I think it's probably just terminology. I consider the daemon to include
the process that listens for incoming connections and all its descendants.

>a message sent locally does not involve the daemon at all.


That's what I'm asking about. From what you say, I think the answer
is that Exim does indeed do local deliveries via setuid privilege
instead of daemon privilege. And apparently for administrator queue
runs too, which I had not considered.

The delivery process does run with the benefit of Exim's setuid
privilege, because without that setuid privilege, the mail sender
would not be able to cause the delivery process to have an effective
uid other than his own. It's that setuid privilege that makes it
unacceptable for the delivery process to inherit the environment.
(the security exposure exists for any effective uid other than the
sender's own, not just uid zero).

I don't need local deliveries to go via this special route; the system
would be simpler and safer if all mail went through SMTP anyway. The
less setuid there is in the system, the better. Now I have to figure
out how to do make that happen.

Administrator queue runs are something to think about. There's no
security issue if the administrator is trusted, and the administrator
would normally have all the right environment in his shell, but it
would just be more robust if that happened in a daemon's controlled
context.


>As an overriding thought, I am not at all sure that relying on
>environment variables in this way is a good idea because it seems to me
>to be very prone to things going wrong.


In general, my experience agrees with your instincts. It's a case of
flexibility allowing mistakes. The alternative most people use is to
hardcode into programs parameters such as file paths. I don't use
hardcoded file paths on my systems except in a few cases of files with
/etc names. That way, files can move around without me rebuilding
programs that use them, I can have multiple installations on one
machine, etc. And I also find it makes the system easier to learn
(and relearn), since you can see the environment variables and the
code that sets them, whereas hardcoded file names aren't so visible.
So on balance, I do prefer to have environment variable control.

I'm using Exim now, but I have to explicitly set all the required
environment variables in exim.conf, whereas everybody else in the
system inherits them naturally.

-- 
Bryan Henderson                                    Phone 408-621-2000
San Jose, California