Re: need for open-minded help with popularity-contest with systemd timer
alimiracle <[email protected]> Sun, 26 Jul 2026 08:56:49 -0700
| Newsgroups | gmane.linux.debian.devel.general |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--------------JCVp5IuPXjvJS15zdHosDkMj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
I think I agree with the direction Simon is describing.
The `sendmail` interface has served Unix systems extremely well for
decades, but it was designed around assumptions that modern service
managers intentionally no longer guarantee. Trying to preserve those
assumptions inside increasingly hardened systemd units feels like
treating the symptom rather than the underlying issue.
An explicit mail submission service with a well-defined API, whether
over D-Bus or another IPC mechanism, would provide a cleaner contract
between applications and the local MTA. It would also make
authorization, auditing, and sandboxing much more predictable than
relying on `setuid`/`setgid` behavior.
At the same time, I hope any new interface remains MTA-agnostic and
simple to implement. One of the strengths of the traditional `sendmail`
interface is that applications do not need to know whether the
underlying MTA is Exim, Postfix, OpenSMTPD, or something else. It would
be great if we could preserve that portability while modernizing the
implementation.
على 7/26/2026 8:34 AM، كتب Simon Richter:
> Hi,
>
> On 7/26/26 18:29, Andreas Metzler wrote:
>
>>> Can we create a systemd service that sends a mail, and has its own
>>> lifetime
>>> and permissions?
>
>> afaiui the important thing when interacting with a local exim is to
>> *not* submit mail from a systemd service via the /usr/sbin/sendmail
>> interface. This avoids having the exim and the respective service in the
>> same cgroup. Submitting by smtp should work avoid this.
>
> /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, so we
> cannot assume that Unix semantics will hold unless there is an
> explicit mechanism for them, and we are seeing breakage precisely
> where we're using a Unix tool inside a non-Unix environment.
>
> The answer to that isn't to hack something to restore enough of the
> Unix semantics to make it work for another release, but to explicitly
> define an interface that does not rely on implementation details of a
> non-hardened environment, because that is not supportable.
>
> 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.
>
> Simon
--------------JCVp5IuPXjvJS15zdHosDkMj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I think I agree with the direction Simon is describing.<br>
<br>
The `sendmail` interface has served Unix systems extremely well
for decades, but it was designed around assumptions that modern
service managers intentionally no longer guarantee. Trying to
preserve those assumptions inside increasingly hardened systemd
units feels like treating the symptom rather than the underlying
issue.<br>
<br>
An explicit mail submission service with a well-defined API,
whether over D-Bus or another IPC mechanism, would provide a
cleaner contract between applications and the local MTA. It would
also make authorization, auditing, and sandboxing much more
predictable than relying on `setuid`/`setgid` behavior.<br>
<br>
At the same time, I hope any new interface remains MTA-agnostic
and simple to implement. One of the strengths of the traditional
`sendmail` interface is that applications do not need to know
whether the underlying MTA is Exim, Postfix, OpenSMTPD, or
something else. It would be great if we could preserve that
portability while modernizing the implementation.<br>
<br>
</p>
<div class="moz-cite-prefix">على 7/26/2026 8:34 AM، كتب Simon
Richter:<br>
</div>
<blockquote type="cite"
cite="mid:[email protected]">
<div class="moz-text-flowed"
style="font-family: -moz-fixed; font-size: 14px;"
lang="x-unicode">Hi,
<br>
<br>
On 7/26/26 18:29, Andreas Metzler wrote:
<br>
<br>
<blockquote type="cite" style="color: #007cff;">
<blockquote type="cite" style="color: #007cff;">Can we create
a systemd service that sends a mail, and has its own
lifetime
<br>
and permissions?
<br>
</blockquote>
</blockquote>
<br>
<blockquote type="cite" style="color: #007cff;">afaiui the
important thing when interacting with a local exim is to
<br>
<b class="moz-txt-star"><span class="moz-txt-tag">*</span>not<span
class="moz-txt-tag">*</span></b> submit mail from a
systemd service via the /usr/sbin/sendmail
<br>
interface. This avoids having the exim and the respective
service in the
<br>
same cgroup. Submitting by smtp should work avoid this.
<br>
</blockquote>
<br>
/usr/bin/sendmail is a Unix interface.
<br>
<br>
It assumes Unix semantics:
<br>
- runs as the calling user
<br>
- has access to the user home directory
<br>
- additional privileges are defined by the sysadmin through
setuid. The distribution provides a default
<br>
- background tasks can linger
<br>
<br>
Systemd explicitly does not want to follow Unix semantics, so we
cannot assume that Unix semantics will hold unless there is an
explicit mechanism for them, and we are seeing breakage
precisely where we're using a Unix tool inside a non-Unix
environment.
<br>
<br>
The answer to that isn't to hack something to restore enough of
the Unix semantics to make it work for another release, but to
explicitly define an interface that does not rely on
implementation details of a non-hardened environment, because
that is not supportable.
<br>
<br>
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.
<br>
<br>
Simon
<br>
</div>
</blockquote>
</body>
</html>
--------------JCVp5IuPXjvJS15zdHosDkMj--