I run exim (exim4-daemon-light) on several machines with nearly
identical setup.  These are configured as "mail sent by smarthost; no
local mail" (satellite).

This one particular machine has been giving me these errors since 1
August.  These errors occur when "mon" sends an email (using sendmail
which is exim4-daemon-light).  This does not happen all the time, and I
cannot figure out what is causing it to happen.  This is a regular ext4
filesystem (no NFS).  The emails get delivered anyway.  The directory
has the following permissions:

# ls -al /var/spool/exim4/msglog/
total 16
drwxr-x--- 2 Debian-exim Debian-exim 12288 Sep 23 00:26 ./
drwxr-x--- 5 Debian-exim Debian-exim  4096 Aug  3 05:44 ../


user:group 111:117 is Debian-exim:Debian-exim.

There is a possibly a similar bug reported for Ubuntu at:
https://bugs.launchpad.net/ubuntu/+source/exim4/+bug/2045253

I can help troubleshoot, but at this moment, I don't know where to begin.

Thanks,

Marc

2024-09-22 16:25:08 1ssU4q-00000001DEL-0AVf <= mon@mclemente.net U=mon
P=local S=920
2024-09-22 16:25:08 1ssU4q-00000001DEL-0AVf exim.c:884:
chown(/var/spool/exim4//msglog//1ssU4q-00000001DEL-0AVf, 111:117) failed
(Operation not permitted). Please contact the authors and refer to
https://bugs.exim.org/show_bug.cgi?id=2391
2024-09-22 16:25:08 1ssU4q-00000001DEL-0AVf Couldn't chown message log
/var/spool/exim4//msglog//1ssU4q-00000001DEL-0AVf: Operation not permitted
2024-09-22 16:26:30 Start queue run: pid=289196
2024-09-22 16:26:32 1ssU4q-00000001DEL-0AVf => marc@mclemente.net
R=smarthost T=remote_smtp_smarthost H=mail.mclemente.net
[2600:3c00::f03c:93ff:fe2f:e5c0]
X=TLS1.3:ECDHE_SECP256R1__ECDSA_SECP256R1_SHA256__AES_256_GCM:256 CV=yes
DN="CN=mail.mclemente.net" A=plain K C=">
2024-09-22 16:26:32 1ssU4q-00000001DEL-0AVf Completed

[...]
[...]

Hello,

mon is invoked by systemd and then executes /usr/lib/sendmail, therefore
exim inherits the the lockdown settings set by
/lib/systemd/system/mon.service. Some of these settings are incompatible
with exim:
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_DAC_READ_SEARCH CAP_SETGID CAP_SETUID CAP_SYS_ADMIN CAP_SYS_CHROOT CAP_SYS_PTRACE CAP_SYS_RAWIO CAP_NET_BIND_SERVICE CAP_NET_BROADCAST CAP_NET_RAW CAP_SYS_ADMIN CAP_SYS_RESOURCE

trial and error shows that adding CAP_FOWNER CAP_CHOWN is needed to get
around the error-message listed above.

Also exim tries to fork off a delivery process which often will need to
look/write to /home which ProtectHome=true breaks. (The delivery process
fails and the message is placed on the queue and delivered later, so
this is not a terminal error.)

cu Andreas

Control: reassign -1 mon 1.4.1-1
Control: retitle -1 mon: systemd service hardening too tight for invoking exim

Hello,

reassigning to mon. @Russell: full quote for context.

cu Andreas