>> The piped-to transport program would be setuid so that it can make
>> local deliveries. It can also handle forwarding, or .forward files
>> can simply be world readable.
>
>Sounds like the pipe-to transport could be Exim <grin>. But yes, if you
>want to do it that way.
And don't think I didn't run into that irony myself in trying to sort
this out. But the difference is that the piped-to transport program
is a much simpler program, and the goal is to have the setuid flag on
the smallest, simplest possible programs so as to avoid opening up a
security hole due to human confusion. In this case, I actually wrote
the piped-to program, so I have way more confidence in my
understanding of what it does in every situation than I have for Exim.
And I certainly don't want to write my own Exim.
>The issue is that root privilege is needed in order to start
>listening on a privileged port.
>> ...
>> It can inherit it's Port 25 socket.
>
>Eh? That doesn't make sense. That socket is long gone. It is part of the
>receiving process and is discarded as soon as the message is safely on
>the spool.
I organized the email poorly. I mean the receiving process can
inherit the socket (when the system starts up). I have a program
called "socketexec" that simply binds a socket and then execs a named
program with it as Standard Input. Kind of like a junior inetd. A
similar program sets uids and such and then execs a named program,
passing on all open files. In combination, a superuser process is
able to start a daemon program without entrusting anything but a
particular reserved port number to it. I use this for lots of daemons
today.
It seems to me it would not be hard to extend Exim to have the option of
inheriting an already bound socket. SIGHUP could work too, since the
re-exec could inherit the same socket.
>The next problem is that, when it has received a message, the daemon
>normally re-execs itself in order to regain root privilege for the
>delivery. You'll have to live without this - all routers will have to be
>able to access whatever they need as 'exim', and all transports will
>have to run as 'exim'.
That's what I'm hoping a setuid (and possibly execute-permitted only
to the exim group) piped-to program can accomplish. And maybe world
readable .forward files.
>> As a mail originator, Exim wants to directly access the mail queue for
>
>Sorry, I can't follow that. What do you mean by "mail queue"? Exim has
>its own queue which of course it must access. What am I missing?
I could have chosen a better word. Mail spool, probably. E.g.
/var/spool/mail/bryanh. Run as a mail originator for locally bound
mail (e.g. someone typing an "exim bryanh <mymessage" shell command), Exim
usually wants to write to /var/spool/mail/bryanh (and probably some
exim-owned files as well), and therefore wants to be setuid. But I'm
claiming that it doesn't have to. It can instead make an SMTP
connection to the local Exim daemon, which requires no privilege at all.
Thus, that one reason for installing Exim setuid root or exim is
avoided. I believe you said a proper configuration file will make
that happen today.
--
Bryan Henderson Phone 408-621-2000
San Jose, California
