I did a quick check for chroot config in /etc via rg -i chroot /etc. Looks fine, I did notice that /etc/default/saslauthd has been configured expecting Postfix not to run in chroot all this time though 🤷‍♂️

The chroot opt-out might be better served as a separate .conf that is included? Easier to undo via user-patches.sh then if a user wants it given the info below.

$ docker run --rm -itd --name dms --hostname example.test --ulimit "nofile=$(ulimit -Sn):$(ulimit -Hn)" mailserver/docker-mailserver:edge
$ docker exec -it dms bash
$ setup email add [email protected] password
$ doveconf | grep -B1 chroot

mail_cache_fields = flags
mail_chroot = 
--
service aggregator {
  chroot = .
--
service anvil {
  chroot = empty
--
service auth-worker {
  chroot = 
--
service auth {
  chroot = 
--
service config {
  chroot = 
--
service dict-async {
  chroot = 
--
service dict {
  chroot = 
--
service director {
  chroot = .
--
service dns-client {
  chroot = 
--
service doveadm {
  chroot = 
--
service health-check {
  chroot = 
--
service imap-hibernate {
  chroot = 
--
service imap-login {
  chroot = login
--
service imap-urlauth-login {
  chroot = token-login
--
service imap-urlauth-worker {
  chroot = 
--
service imap-urlauth {
  chroot = 
--
service imap {
  chroot = 
--
service indexer-worker {
  chroot = 
--
service indexer {
  chroot = 
--
service ipc {
  chroot = empty
--
service lmtp {
  chroot = 
--
service log {
  chroot = 
--
service managesieve-login {
  chroot = login
--
service managesieve {
  chroot = 
--
service old-stats {
  chroot = empty
--
service pop3-login {
  chroot = login
--
service pop3 {
  chroot = 
--
service quota-status {
  chroot = 
--
service quota-warning {
  chroot = 
--
service replicator {
  chroot = 
--
service stats {
  chroot = 
--
service submission-login {
  chroot = login
--
service submission {
  chroot = 
--
service tcpwrap {
  chroot = 
--
}
valid_chroot_dirs =

Of those we can see most are empty, but we can see the following services are set:

chroot = .

• aggregator
• director

chroot = empty

• anvil (dovecot default)
• ipc
• old-stats

chroot = login (all these are dovecot default)

• imap-login
• managesieve-login
• pop3-login
• submission-login

chroot = token-login

• imap-urlauth-login

Dovecot docs for Login processes mention chroot purpose:

• A dovenull user is chrooted into a read-only directory that contains only unix sockets for authentication.
• Describes disadvantage of opt-out from chroot for login processes:

  This loses much of the security benefits of the login process design, because in case of a security hole (in Dovecot or SSL library) the attacker is now able to see other users logging in and steal their passwords, read their mails, etc.

These Dovecot Rootless docs mention similar risks and only document removing the same three services the PR presently is dropping chroot for (imap-login, pop3-login, anvil). The user and group variables mentioned there are the defaults dovecot (internal user/group) and dovenull (login user).

Despite anvil being documented as empty in the service docs linked earlier (and output of doveconf), this changelog (for 2.4 / 3.0, presently unreleased) mentions that it will be unset.

Another user provided similar input for fixing the chroot issue citing Dovecot Rootless instructions back in Feb. They also used rootless Podman, and reported chroot permission errors with anvil which we now know is due to a Podman release in Feb dropping the default capability CAP_CHROOT. The linked comment also references a Mailu project issue where SYS_CHROOT is needed for another container runtime.

I've not seen any config for chroot with Dovecot being opt-out in a quick glance at mailu or mailcow. Neither uses chroot for Postfix though.

As per the postfix chroot opt-out PR, it's unclear how beneficial chroot is (although Dovecots usage differs?). I previously referenced chroot is not a security measure, not much changes here I think? If other processes like Postfix were compromised in a similar fashion, they'd have access to the same contents of /var/mail or any other part of the container.

LGTM 👍

Thanks for putting this together 😀

Was a pleasure to help you :) I will adjust the v12.0.0 release PR now & later after lunch and make sure everything is heading the right direction there.