Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Systemd service

102 views
Skip to first unread message

Craig Andrews

unread,
Jun 27, 2016, 11:18:52 AM6/27/16
to
I think it would be great if postfix could include and install a systemd service.

Currently, each distribution is required to write its own systemd service. This situation is less than ideal because work is duplicated and there is a lot inconsistency. I think it makes more sense to develop the service definition upstream and include it as part of the postfix release so each distro has a solid, consistent, supported starting point, and distros can collaborate via the postfix project (ex, this mailing list) to improve the service over time.

I've attached a systemd service definition that I think would work well.

Note that I'm not suggesting that postfix link against systemd... just distribute the service definition and (perhaps optionally?) install it from postfix-install. :-)

Thanks,
~Craig

===postfix.service===
[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
ExecStartPre=-/usr/bin/newaliases
ExecStart=/usr/sbin/postfix start
ExecStop=/usr/sbin/postfix stop
ExecReload=/usr/sbin/postfix reload
# Hardening
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=full
# Perhaps someone can suggest a tighter capability set, hopefully using whitelisting instead of blacklisting?
CapabilityBoundingSet=~ CAP_NET_ADMIN CAP_SYS_ADMIN CAP_SYS_BOOT CAP_SYS_MODULE

[Install]
WantedBy=multi-user.target
===end postfix.service===

Andrea Pappacoda

unread,
Jun 19, 2022, 8:50:15 AM6/19/22
to
Hi Craig, sorry for my super late reply! Hope you didn't forget about this :)

Il giorno lunedì 27 giugno 2016 alle 17:18:52 UTC+2 cand...@integralblue.com ha scritto:
> I think it would be great if postfix could include and install a systemd service.
>
> Currently, each distribution is required to write its own systemd service. This situation is less than ideal because work is duplicated and there is a lot inconsistency. I think it makes more sense to develop the service definition upstream and include it as part of the postfix release so each distro has a solid, consistent, supported starting point, and distros can collaborate via the postfix project (ex, this mailing list) to improve the service over time.

I agree. Currently, pretty much all major distributions ship Postfix with a systemd service, and it would be nice if the improvements of the community could be upstreamed so that everybody can benefit from a unified systemd service, without all the minor differences between Linux distros.

I've been running a hardened Postfix service for a little while too, and while it is way more restrictive than what you proposed here it has worked great for me so far.

I've used the Postfix systemd service from Debian as a starting point; here it is:

$ systemctl cat postfix@.service
# /lib/systemd/system/postfix@.service
[Unit]
Description=Postfix Mail Transport Agent (instance %i)
Documentation=man:postfix(1)
PartOf=postfix.service
Before=postfix.service
ReloadPropagatedFrom=postfix.service
After=network-online.target nss-lookup.target
Wants=network-online.target

[Service]
Type=forking
GuessMainPID=no
ExecStartPre=/usr/lib/postfix/configure-instance.sh %i
ExecStart=/usr/sbin/postmulti -i %i -p start
ExecStop=/usr/sbin/postmulti -i %i -p stop
ExecReload=/usr/sbin/postmulti -i %i -p reload

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/postfix@.service.d/override.conf
[Service]
CapabilityBoundingSet=CAP_DAC_READ_SEARCH CAP_NET_BIND_SERVICE CAP_SETGID CAP_SETUID CAP_SYS_CHROOT
LockPersonality=yes
MemoryDenyWriteExecute=yes
NoNewPrivileges=yes
PrivateDevices=yes
PrivateTmp=yes
ProcSubset=pid
ProtectClock=yes
ProtectControlGroups=yes
ProtectHostname=yes
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectKernelTunables=yes
ProtectProc=invisible
ProtectSystem=full
RestrictAddressFamilies=AF_INET AF_INET6 AF_NETLINK AF_UNIX
RestrictNamespaces=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service @mount
SystemCallFilter=~ @resources

How does it look to you?

Thanks :D
0 new messages