22.12.2024 10:24, Helmut Grohne wrote:
Hi Michael and Simon,
Hello Helmut! :)
On Wed, Dec 18, 2024 at 10:16:12PM +0900, Simon Richter wrote:
If they were to ship unit files, they'd end up in the same documentation
..
I'm not sure the generator approach needs to be ruled out that quickly. The fields of master.cf map quite nicely to systemd. I'd interpret
Heh. Please pause and exhale here. We are not going to ship unit files for individual Postfix components. Yes, the idea is very interesting, and it's quite something which goes to mind when one think about it from a distant perspective. However, for this to be anyhow real, postfix has to be changed. Maybe not much, but it definitely needs quite some tweaks. Because while the concepts are similar to what's available in systemd, the actual implementation is different and at the very least, some shim layer needs to be implemented for this to work. Also, postfix processes does the sandboxing internally and voluntary, it is not the master process who does the sandboxing, - master process merely gives args to a common postfix main() routine, which does the rest of the work - because in many cases, root-time init is needed. We're NOT shipping unit files for Postfix daemons. ...
Going back to the initial question of chrooting, I guess the main work is done as chroot is what installations do by default. In the event that chroot poses a problem (which seems to be rare), individual processes may be opted out of chrooting in master.cf at ease. Users who strongly care about security would likely separate their installation into multiple Postfix instances one of which is facing to the internet and another to perform delivery to local users (likely running on different machines). The status quo does not look bad enough to me to warrant serious investment here, but maybe I am not enough of a power user of Postfix to understand the pain caused by chroots.
I dug into this hole (or swamp). Initially I was strongly against using chroot by default, - for 25 year already. The same is true for the upstream. However, after seeing all the bug reports in our BTS, re-reading numerous questions on postfix-users@, various guides on the 'net related to Postfix and Debian... it feels like most issues we caused to Postfix community and users are not because chroot is really painful, but because of insufficient support of this concept on the Debian end. Most of the pain could've been avoided entirely if the correct approach were taken at the beginning and sticked to. However, *some* aspects are painful indeed. It took me quite some time to figure it all out. For example, when the talk is about SASL authentication, the first thing which comes to mind is Cyrus SASL (there's also Dovecot SASL, and it is quite capable to be used by its own, but in people minds it is an integral part of Dovecot and "since I don't use Dovecot, its SASL is not for me"). So, people choose Cyrus SASL. Which has little understood defect or a limitation: its initial saslauthd implementation and protocol is limited to verifying just username+password (it is a pwcheck method). So it only supports PLAIN/LOGIN, nothing more. All the other SASL mechanisms are done as plugins (auxprop, ie, using auxiliary properties, not just user and password) within application address space, - in our case, they all work within Postfix smtp[d] - which, by default, is running chrooted. So all guides on the 'net end up doing `mv /etc/sasldb2 /var/spool/postfix/etc/`, which is an insane thing to do. And there's no way to fix this in current infrastructure, besides switching to dovecot auth (which works by implementing a higher-level protocol than saslauthd does). Also, current glibc has interesting properties wrt chroot and nsswitch.conf (and hence libnss modules). It is neither bad or good thing, it is just something which needs to be taken into account when running anything in a chroot - postfix packaging hasn't changed in this place since 2001 or so, - current glibc works differently. Hopefully I'll fix this part in postfix for good before trixie. So overall, things seemed rather good, despite all the hate (from me and whole postfix community) this chroot-by-default decision in debian received, except a few cases, some of which are easy to fix while some aren't and it's actually better to un-chroot parts of postfix. Again, there was no easy way to turn the chroot off - current postfix package in debian provides a trivial command for this: `postfix chroot off' (and `postfix chroot on' to turn it on). Please note also that there are a LOT of guides on the 'net about setting up postfix on debian/ubuntu, all of them assumes postfix is running chrooted, and most of them will just break if we're to un-chroot it out of the sudden - people will start asking "why it doesn't work anymore". With all this, I have a small hope there might be no need to revert that 25 years old decision which made so much pain. I think there should be a debconf question asking if the user wants to (un)chroot it. Dunno which default answer to have though. With a really easy way to toggle already present. Thanks, /mjt
