6

With compatibility_level=2 in recent postfix versions, the default for the postfix daemons changed from chroot to non-chroot. While the page describes that it changed and what you can do to continue using chroot or stop using it, there are no reasons given.

Why did they change the default value? Is there any advantage in running it without chroot?

Improve this question
2
  • I'd like to know this as well, so you're not the only one asking this (although, at the time of writing this comment, the question has only been viewed 26 times in 3 months).
    – bovender
    Dec 18, 2017 at 13:06
  • @bovender I only realised the default configuration for chroot had been changed when I eventually got around to resolving the Postfix is running with backwards-compatible default settings notice in my logs. I came across this question while wondering about the reason. Since there was no answer, I decided to research the issue and provide my own answer.
    – Anthony Geoghegan
    Feb 1, 2019 at 15:45

1 Answer 1

Reset to default
6

If you download the Postfix source code and examine the HISTORY file, you can see that this change was made on the 1st October 2014 (Snapshot 20141001):

New defaults for master.cf chroot (n), append_dot_mydomain (no) and smtputf8_enable (yes).

The corresponding git commit shows all the changes that were made to the source code and documentation at this time. Unfortunately, there’s little explanation of the reasons for changing this default setting.

As you’ve already noted, the Postfix Backwards-Compatibility Safety Net states that

The new default avoids the need for copies of system files under the Postfix queue directory.

And the Postfix Basic Configuration

If your machine has unusual security requirements you may want to run Postfix daemon processes inside a chroot environment.

Some Internet searching turned up a few clues to the rationale behind this change:

In a 2008 discussion on the use of chroot, Wietse said

I think it is inappropriate to chroot Postfix by default. Chroot make sense on dedicated firewalls. General-purpose desktops run web browsers and have a much bigger attack surface than Postfix will ever have.

Later in 2011

Chroot support makes sense for sites that have very restricted access policies.

I also read the following in the SASL_README from Postfix 2.6:

To run software chrooted with SASL support is an interesting exercise. It is not worth the trouble.

The text of this file has changed in more recent releases but this indicates that there were issues being caused by running the mail server in a chroot jail. Scanning through the archives of the postfix-users mailing list shows that this was causing problems with some users.

I personally run Postfix in a chroot jail and, while I don’t use saslauthd, I did have to take a few extra steps configuring milters so that they could communicate with chrooted Postfix daemons via Unix sockets.

Improve this answer
1
  • I can also add that chroot causes issues with some milters and is not expected by most users that don't have experience with postfix (I just spend 3 hours debugging why postfix cannot connect to opendkim).
    – HubertNNN
    May 29, 2023 at 15:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .