On mail.quux, a node of NNCPNET (the NNCP-based peer-to-peer email network), I started noticing emails not being delivered. They were all in the queue, frozen, and Exim’s log had entries like:
unable to set gid=5001 or uid=5001 (euid=100): local delivery to [redacted] transport=nncp
Weird.
Stranger still, when I manually ran the queue with sendmail -qff -v, they all delivered fine.
Huh.
Well, I thought, it was a one-off weird thing. But then it happened again.
Upon investigating, I observed that this issue was happening only on messages submitted by SMTP. Which, on these systems, aren’t that many.
While trying different things, I tried submitting a message to myself using SMTP. Nothing to do with NNCP at all. But look at this:
jgoerzen@[redacted] R=userforward defer (-1): require_files: error for /home/jgoerzen/.forward: Permission denied
Strraaannnge….
All the information I could find about this, even a FAQ entry, said that the problem is that Exim isn’t setuid root. But it is:
-rwsr-xr-x 1 root root 1533496 Mar 29 2025 /usr/sbin/exim4
This problem started when I upgraded to Debian Trixie. So what changed there?
There are a lot of possibilities; this is running in Docker using my docker-debian-base system, which runs a regular Debian in Docker, including systemd.
I eventually tracked it down to Exim migrating from init.d to systemd in trixie, and putting a bunch of lockdowns in its service file. After a bunch of trial and error, I determined that I needed to override this set of lockdowns to make it work. These overrides did the trick:
ProtectClock=false PrivateDevices=false RestrictRealtime=false ProtectKernelModules=false ProtectKernelTunables=false ProtectKernelLogs=false ProtectHostname=false
I don’t know for sure if the issue is related to setuid. But if it is, there’s nothing that immediately jumps out at me about any of these that would indicate a problem with setuid.
I also don’t know if running in Docker makes any difference.
Anyhow, problem fixed, but mystery not solved!