Summary

  • Postfix’s privileged master gives most service daemons the chance to open necessary files during initialization and then drop root before processing requests; four delivery services retain a saved root identity for bounded tasks.
  • The unprivileged-master option narrows the supervisor’s privilege but removes some internal separation, makes secrets and logs more exposed to a compromised service, and is approved for only a limited set of production configurations.

The first security question in a mail system is often framed too simply: does it run as root? Postfix’s architecture makes the more useful question local. Which process needs which privilege, at what point in a request, and over which files or other users’ resources?

A message received over SMTP or QMQP first reaches a network-facing Postfix service. That service checks the input and passes the envelope and message to cleanup(8). Cleanup performs the last processing before queueing, writes the message into the incoming queue and notifies qmgr(8). The queue manager chooses delivery agents for the next step. It keeps only a limited active queue, so a large backlog does not require it to open every queued message at once. The resident master(8) process supervises this collection of services, starts them on demand and enforces configured process limits.

This division matters because the supervisor and the request-handling daemons do different jobs. In Postfix’s privileged-master model, a service can start with root privileges, open sensitive files such as TLS private keys or database passwords, and then irrevocably give up root before it handles requests. The current security documentation says a service compromised after that drop can no longer open those sensitive files, databases or log files. Root is therefore part of initialization and privilege selection, not a blanket permission for every network-facing process throughout its lifetime.

The model has exceptions. Most services permanently drop root, but local(8), pipe(8), spawn(8) and virtual(8) retain a saved effective root identity. They need it to switch to a target user or operate on a non-Postfix resource, such as a mailbox or an external command. Postfix distinguishes these uses: root can separate privileges among Postfix services, and it can confine Postfix when a service crosses into a user’s files or a non-Postfix program. A single label such as “root process” hides those separate boundaries.

Wietse Venema described Postfix as a partitioned least-privilege architecture in a 2010 LISA presentation. He traced one influence to a firewall design that separated mail receipt from delivery with low-privilege, chrooted processes. The presentation also explains why separate programs can help maintenance, once the communication infrastructure exists. That is a historical account of the design, not a present-day count of Postfix daemons or a measurement of security outcomes. The current architecture documentation supplies the operational detail: message reception, cleanup, queue management and delivery remain distinct services.

The recent change is not a claim that removing root from the supervisor automatically makes the entire system safer. Postfix’s documentation says Venema first implemented unprivileged master(8) operation for unreleased integration tests in 2025. After a customer inquiry in 2026, he adapted it for limited production use and added documentation. Under this mode, the master runs with the fixed postfix identity instead of root. Services then have the same Postfix privileges during initialization and while handling requests. The documentation says this cannot preserve Postfix’s internal privilege separation or the usual confinement when accessing non-Postfix files, delivering to mailboxes or executing external commands.

That choice has practical consequences. Postfix secret-key files must be readable by the postfix user. A compromised service can therefore read them. Optional Postfix log files must be owned by postfix, so a compromised service can read, alter or delete those records. Configuration must remain outside the postfix user’s ownership. In a multi-instance setup, all instances must use privileged master operation or all must use unprivileged master operation; the two modes cannot be mixed.

The production boundary is narrow. The documentation permits unprivileged master for deployments that forward all messages using SMTP or LMTP. It says not to use that mode in production when local services may execute non-Postfix programs or deliver to mailbox files. One stated risk is that a command in a user’s .forward file would run with postfix privileges instead of that user’s privileges, giving the user a path to control the mail system. The warning is configuration-specific, but it is explicit.

The architectural lesson is not “root is safe” or “root is unsafe.” It is that permission changes move risk between boundaries. A master without root may be attractive in a constrained relay deployment, but the service processes share access to secrets and logs that the privileged model can keep behind an initialization-and-drop boundary. Operators need to classify their delivery paths before changing the master’s identity, then check that the chosen mode still matches the files and commands each service can reach.

The public documentation defines that trade-off; it does not establish how often operators choose either mode or what security results follow in live deployments.

Sources