Hi Michael and Simon, On Wed, Dec 18, 2024 at 10:16:12PM +0900, Simon Richter wrote: > Postfix's "master" process effectively implements an orchestrator for a > microservice architecture, similar to what systemd does. This could be > replaced by systemd by writing a generator that creates units from > master.cf.
Thank you for the excellent explanation. > Simply converting the default master.cf to unit files and shipping these as > default would still be a massive regression, because it would obsolete a lot > of documentation on how the Postfix system is orchestrated and how to > integrate new services like clamav and spamassassin or to deliver to > courier. I would like to dive slightly deeper into the prospect of eliminating the master process. You already gave a very good account on the usability aspects, but the technical aspects seem worth a bit more exploration to me. Postfix does not chroot all services. If it were, local delivery would not work. The value we gain from the orchestrator here is that it separates functionality into different processes somewhat isolated from one another to limit possible blast radius. The network facing smtp process has no business accessing user's $HOME. The way we get there today is chroot. If viewing this from a systemd angle, we would not want to chroot the smtp process and rather hand it its own mount namespace where /home (and other pieces) are rendered inaccessible (e.g. via ProtectHome or it being implied). Postfix upstream cannot rely on these mechanics, because it wants to support non-Linux deployments where mount namespaces are unavailable. > If they were to ship unit files, they'd end up in the same documentation > nightmare as we would if we were to start doing so, and if they create a > generator and start using systemd as the controlling process, they would not > gain anything, because neither can they drop their own orchestrator (so this > creates additional testing surface, as their services would now need to > implement *two* service manager protocols), nor would that directly provide > any additional functionality. 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 "chroot" diferently and map to ProtectSystem (or similar) instead and at that point we alleviate the initial concerns that Michael posted in his initial mail (e.g. nsswitch). This is where we gain something compared to keeping Postfix' master process. Many of the units are socket-activated in a very similar way to how systemd understands socket activation. Most postfix processes perform an idle-exit, so your typical system only sees few of them at the same time. This approach is not without downsides. I'm not going to repeat Simon's. We'd also end up with a *lot* of .service units (30 in a typical installation). systemd developers may disagree with using a generator for orhestrating systemd units inside a master.cf file. 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. Going
