https://bugs.exim.org/show_bug.cgi?id=1925
Heiko Schlittermann <hs@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hs@???
--- Comment #6 from Heiko Schlittermann <hs@???> ---
The problem in sandboxed environment arises because Exim needs privilege
escalation to access the spool directories. Using a fallback spool directory
(/tmp or some other writable place) doesn't seem to be wise, because
independend queue runner processes won't find these spools without additional
effort.
(And we might get even more security issues.)
Delivering the message to a local inet listener should be simple and does not
need additional privileges. Unfortunately some Unix tools still need to pass
the message via a pipeline into 'sendmail' or 'sendmail -t'.
While there exist simple replacements for sendmail (e.g. ssmtp) which just
accept the message and deliver it via SMTP to some smarthost, I'd like to see
an Exim provided solution.
Delivery via the inet socket loses the identity of the sender. If we would
install a small non-suid binary as sendmail, taking the id of the calling
process (as Exim does currently) and forward the message via SMTP to a local
inet socket, we can pass the identity information via the AUTH=.... MAIL
parameter.
Or - Exim could listen on a UNIX socket. I think on a Unix socket, the server
can get the peer identity ((r|e)uid of the connecting process). This way Exim
has a trusted source of the sender identity, as it would have when called the
traditional way. For this solution we only need an even more simple wrapper
'sendmail', that forwards its standard input to unix:/run/exim.socket.
Just some ideas.
--
You are receiving this mail because:
You are on the CC list for the bug.
