Auteur: Russell King Date: À: exim-users Sujet: Re: [exim] Spurious permission denied error
On Tue, Apr 28, 2020 at 11:38:28AM +0300, Evgeniy Berdnikov via Exim-users wrote: > On Tue, Apr 28, 2020 at 08:59:58AM +0100, Russell King via Exim-users wrote:
> > On Tue, Apr 28, 2020 at 10:38:13AM +0300, Evgeniy Berdnikov via Exim-users wrote:
> > > 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.)
>
> Root obeys file permissions, but generally it have more permissions
> than ordinary user.
root can read this file, despite not being the owner, and not having
"other" mode bits set. To take this to the extreme:
# chmod 0 testsend
# ls -l testsend
---------- 1 patchd nogroup 105 Apr 28 08:34 testsend
# cat testsend
From: patchd
...
> > 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.
>
> Take one minute to think. User runs MTA as "/usr/sbin/sendmail -oi -t",
> passing argv[0..2] = ["/usr/sbin/sendmail", "-oi", "-t"]. You have to
> replace argv with ["-d+all", "-oi", "-t"] and run exim binary from other
> location, where it may stay with setuid bit. No magic here, no need for
> special priveleges, it can be done with 2 lines shell script:
>
> #!/bin/sh
> exec /usr/sbin/exim -d+all "$@"
>
> This script does not ever need to be setuid.
While that much is true, it is you who need to think, and actually read
my email messages.
As I said, due to the security in exim, you can _not_ use debugging if
exim is called from a non-privileged user - it is an option that is
denied to the user.
The second issue: you can not have setuid scripts on Linux. Yes, you
can set the setuid bit on a script, but the kernel will not honour it.
If you don't believe me, try running this script as a normal user with
the script setuid root on Linux:
#!/bin/sh
id
"id" will tell you that the script is not running root.
So, an all three points you've raised, you are very much mistaken and
it seems you're confused.