On Tue, Apr 28, 2020 at 10:38:13AM +0300, Evgeniy Berdnikov via Exim-users wrote:
> On Tue, Apr 28, 2020 at 08:12:30AM +0100, Russell King via Exim-users wrote:
> > I believe so - exim is being called from a perl script running as the
> > user stated in the log line thusly:
> >
> > /usr/sbin/sendmail -oi -t
> ...
> > > If you have root, the moral equivalent of
> > >
> > > # service exim stop && exim -d+all -bd 2>&1 | tee log
> > > ...
> > > ctrl-c
> > > # service exim start
> > > # less log
> >
> > How does that help when the process that accepted the message and
> > delivered it was started by the user concerned, and the message
> > was not handled by the daemonised exim?
>
> Write a wrapper over /usr/sbin/sendmail which should start exim
> as root and with additional debug flags.
I don't think that will work based on my testing so far.
If exim is started as root, then the problem goes away (which is not
surprising because root can generally do anything, bypassing file
permissions.)
That is the exact problem getting debug in this situation: you need
exim to be invoked as the user concerned to then drop privileges
back to an unprivileged user to then trigger the permission denied
error. However, you can't enable debug.
If you run exim as root, it doesn't seem to do that, so the error
doesn't occur, but you can enable debug.
> > Due to the implemented security on setuid processes started by non-root
> > users, I don't think I can.
>
> If you have root access to this machine, you can do anything.
> If you are not, just delegate this work to sysadmin.
Respectfully, I don't think you've thought about the problem. How do
I start exim as a user, get it's PID, to then launch a strace session
from the root shell before the process finishes? It takes less than
a second between the message being submitted and the error occurring.
The protection on setuid processes means that while you can do this:
strace /usr/sbin/sendmail -oi -t
as an unprivileged user, the process will no longer be executed setuid,
and it definitely will not be able to access a bunch of files (such as
those giving it the credentials for the smarthost.)
I've tried setting hold_domains in the exim config file, submitting
a test message as the unprivileged user, then manually running a
delivery (exim -d+all -M <spoolid>) as root, and, as expected, there
is no permission denied error _because_ it's being executed as root,
and "root can do anything".
--
Russell King
