On Mon, 19 May 2025 at 12:29, Marc Haber <[email protected]> wrote: > > On Sat, May 17, 2025 at 06:58:56PM +0100, Richard Lewis wrote: > >There is a known 'incompatibility' between systemd and exim that both > >upstreams have explicitly declined to address - but it's > >not clear (to me anyway) why you are hitting this -- ive been using > >systemd and logcheck (and several other local email-sending units) for > >over > >a year with hardening and (after much pain) it now works for me - i > >get an email every single day from a shell script in a systemd unit. > > And all those scripts alos deliver via /usr/lib/sendmail?
not sure --- i just use mail (from mailutils) -- and logcheck uses mime-construct -- these may call sendmail ? > Are you refering to the suid issue that I mentioned or is that > incompatibility something else? not sure -- https://systemd-devel.freedesktop.narkive.com/nV1QMO8j/exim4-only-queues-mails-sent-by-systemd-service is what i am trying to describe, i dont think it is only about suid, but i may be wrong > >that was my first thought, but i am no longer sure - i think that it is also > >possible that exim delivers the email but, before it can remove it > >from the queue, systemd > >tears down the logcheck unit, and so exim retries, and this makes a > >duplicate. > > I have yet to see log evidence that exim actually delivers the message > twice. Me neither -- this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1106030 is the only reproducible "issue" i have seen in the logcheck unit (and it doesnt match this bug) @Marc Haber would love your more expert view on that bug - and to correct the likely flawed terminology in there!) ps, my other email-sending units work with the following hardening (not complete) - as long as i add a "sleep" after sending the email. (but logcheck us using has none of these) ProtectSystem=strict ReadWritePaths=-/var/spool/exim4 -/var/mail -/var/log/exim4 # (ProtectHome=true works, but the email is frozen) ProtectHome=read-only RestrictSUIDSGID=true AmbientCapabilities= CapabilityBoundingSet=CAP_SETGID CapabilityBoundingSet=CAP_SETUID CapabilityBoundingSet=CAP_FSETID CapabilityBoundingSet=CAP_CHOWN CapabilityBoundingSet=CAP_DAC_OVERRIDE CapabilityBoundingSet=CAP_FOWNER i noticed your aide one used quite different capabilities. i only found these with trail and error, and none are relevant to debian's unit, as far as i can see
