On 2024-12-17 07:32, Michael Tokarev via Postfix-users wrote:
>
> Isn't the only reason maldrop is setgid is to be able to access
> /var/mail/$USER ?
> Which is a sort of legacy these days too, and is solved entirely by
> switching to ~/Maildir/ or other means to store email?
Nope, it's about access to /var/spool/postfix/{maildrop,public}.
I've solved this in mimedefang.service (as it's the only client in my
setup allowed to maildrop):
[Service]
ExecStartPre=-!setfacl -m u:defang:wX /var/spool/postfix/maildrop
ExecStartPre=-!setfacl -m u:defang:X /var/spool/postfix/public
Alternatively I could use:
SupplementaryGroups=maildrop
(for non-systemders: this provides additional group access per-service,
without extending it permanently in /etc/group).
>> But /dev/log in systemd is datagram socket...
>
> Hm. Is this yet another myth we're facing here?
Well, there were lots of anti-systemd in the old days, most of them were
simply uninformed and spread falsehood.
This is the unpopular fact, that many, if not most, Linux system
administrators is not more qualified to do this job, than their lusers.
Just look for bashisms in #!/bin/sh scripts (or #!/bin/bash itself,
everyone knows zsh is superior;>).
And - this is the fact, systemd has steep learning curve. Having - back
then, 20 years of experience in development, SysV, POSIX, SUSv3 is
wasn't a walk in the park, especially when facing things like FHS
non-conformance. Putting this with linux ecosystem not being ready
(CGroups v1, no support for v2 in docker for a long time, security
issues with user namespaces or BPF, no support for idmapped mounts,
problems with dbus and kdbus drama) left a deep mark on systemd, which
in fact triggered or exposed problems in subsystems, that before systemd
were simply not used enough.
There are still problems left, like replacing dbus (which is reference
implementation) with pid1/dbus-broker and now with varlink, capabilities
scope (infamous CAP_SYS_ADMIN), poor possibilities of polkit,
SCM_CREDENTIALS missing something I can't recall right now...
But the systemd adaptation simply made this important and finally addressed.
And anyone who has previously been maintaining SysV init scripts knew,
what kind of hell it was compared to declarative syntax, sandboxing,
isolation, dependency tracking and supervising available now OOTB.
No more servers stuck just before reboot due to a hanging process, no
more worries about booting server with LUKS over MD over integrity over LVM.
I can finally have read-only root login (nothing bulletproof, but at
least no accidental damage), reliable service termination, user session
management etc. At a cost of knowing how to handle all of this.
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
