Re: need for open-minded help with popularity-contest with systemd timer

On Wed, 29 Jul 2026 at 13:27:05 +0100, Richard Lewis wrote:
>Simon Richter <[email protected]> writes:
>> /usr/bin/sendmail is a Unix interface.
>>
>> It assumes Unix semantics:
>>  - runs as the calling user
>>  - has access to the user home directory
>>  - additional privileges are defined by the sysadmin through
>>    setuid. The distribution provides a default
>>  - background tasks can linger
>>
>> Systemd explicitly does not want to follow Unix semantics

Perhaps more accurate to say that the traditional Unix semantics 
involved "each program can more or less do what it wants", and by 
default systemd enforces a subset of what was traditionally allowed, 
which has advantages and disadvantages.

Specifically, the thing that breaks exim seems to be that systemd 
doesn't normally let background tasks linger as part of a service after 
the service "should" have exited, in an effort to make process and 
cgroup lifetimes and ownership on the overall system something that is 
easier to reason about: if popcon.service asks to send an email, then 
exits, the worldview that systemd encourages is that it is unexpected to 
have a daemonized exim process still hanging around in popcon.service's 
cgroup ("part of popcon", not "part of exim"!) to carry out the actual 
delivery.

And, separately, the thing that breaks postfix (and possibly exim, not 
sure) is that systemd encourages authors of service definitions to apply 
a least-privilege level of sandboxing/hardening to each service, some of 
which involves PR_SET_NO_NEW_PRIVS to disarm setuid/setgid, and that 
conflicts with assumptions made by postfix (and possibly exim).

If delivering email with exim (or postfix) requires relaxing what 
systemd normally allows, that gives us a scalability problem where each 
service that might send email needs to be reconfigured to have 
sufficiently unrestrictive access to allow everything exim wants to do, 
and also everything that postfix wants to do, and so on.

We'd have similar problems if popcon was running under a restrictive 
AppArmor profile, or any other source of sandboxing/hardening - systemd 
isn't really special here.

>cleaning up broken lingering processes is a nice benefit of systemd

Indeed. But systemd can only do this because, by default, it places a 
constraint on the managed service: "lingering processes are assumed to 
be brokenness". If you turn off that constraint for a service (which is 
possible but discouraged) then systemd can no longer give you the 
corresponding benefit, because it can't tell the difference between 
broken lingering processes and intentional lingering processes.

>i think just the last one is the issue. but is that really part of the
>sendmail interface or an accident of how exim implements it?

The point is that exim makes assumptions that were (accidentally or 
deliberately) true on traditional Unix systems, but as part of systemd 
(or individual systemd service files) giving services a more narrow set 
of constraints, some of those assumptions are no longer true.

>> So: if there should be a way for a program to send mail, there needs
>> to be a dbus service, with proper authorization through the policy
>> framework.
>
>dbus seems a but overkill?

Specifically, what's needed is a way to submit a request in execution 
environment A, such that the request arrives at an exim or postfix 
service in execution environment B, and then exim or postfix can take 
over responsibility for acting on that request (delivering mail).

Often the best way to do that sort of cross-domain communication is to 
have a process listen on an AF_UNIX socket, and make the requester 
connect to the AF_UNIX socket and talk to it, ideally using SO_PEERCRED 
or SCM_CREDS to identify the caller's uid from unforgeable 
kernel-provided information instead of needing to use passwords/secrets 
for authentication. Path-based AF_UNIX sockets have the advantage that 
can be bind-mounted into chroots or containers (if you want to allow 
communication) or not bind-mounted (if you want to deny communication), 
unlike abstract AF_UNIX sockets and networking protocols like TCP/UDP 
(which are difficult to allow/deny for sandboxed services at a level 
that is not all-or-nothing).

D-Bus on the system bus (requests encoded as D-Bus messages and sent 
through an AF_UNIX socket to the message bus, which passes the request 
to the implementor) is one popular way to do this; that removes the need 
to design the low-level messaging protocol and its security model on a 
per-application basis, which is why quite a lot of newer system services 
like NetworkManager and systemd use it.

But it could equally well be SMTP over AF_UNIX (do MTAs implement that?  
perhaps they should?), or SMTP over TCP to 127.0.0.1:587 or [::1]:587 or 
:25, or varlink over AF_UNIX, or some other mail submission protocol 
like LMTP over AF_UNIX or TCP.

SMTP over TCP is the lowest-common-denominator email submission 
protocol, but any protocol over TCP has the big disadvantage that it's 
necessary to be able to authenticate the sender in some way, if you want 
any access control beyond "every process on this machine can send email, 
and the system can't tell which process/user was responsible".

     smcv