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

Simon McVittie <[email protected]> writes:

> 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 abou


thabks - this is very helpful and i agree with all of this

> 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).
>

this but is easy to work round by not applying the appropriate
directives - it would be good if the debian wiki had a page on what
to do for postfix.



>>> 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?
>

> 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".
>

(isnt the bit in quotes exactly what the current sendmail interface
provides, perhaps changing it should be left for another day?)