Question: permissions for /run/dovecot/replicator unclear #5

Thorarin commented 2026年02月20日 19:45:46 +01:00

I've just started using Wormhole for my small scale mail system. I had already upgraded from dovecot 2.3 a while ago and just put a cron job with periodic sync for the time being. Anyway, I'm struggling to understand the unix socket permissions.

I'm using mostly Debian 13 defaults. The dovecot/imap process is running as the mail user (in this case marcel). Other processes run as dovecot/dovenull and some as root:

# ps -Af | grep dovecot
root 2669191 2669190 0 19:13 ? 00:00:00 dovecot/anvil
root 2669192 2669190 0 19:13 ? 00:00:00 dovecot/replicator
root 2669193 2669190 0 19:13 ? 00:00:00 dovecot/log
root 2669194 2669190 0 19:13 ? 00:00:00 dovecot/config
dovecot 2669195 2669190 0 19:13 ? 00:00:00 dovecot/stats
dovecot 2669196 2669190 0 19:13 ? 00:00:00 dovecot/auth
dovenull 2669227 2669190 0 19:13 ? 00:00:00 dovecot/imap-login
marcel 2669327 2669190 0 19:15 ? 00:00:00 dovecot/imap
root 2669328 2669190 0 19:15 ? 00:00:00 dovecot/auth -w

The issue I'm having is with the permissions for the unix socket /run/dovecot/replicator.
Its permissions seem to default to root:root and 0666. https://codeberg.org/errror/wormhole/src/branch/main/doc/replication.md mentions that 0666 permissions are okay'ish for replication-notify, but I doubt this is the case for this particular socket.

Using an adapted sample configuration, the replication is not working and these errors are logged every time there is something to sync:

Feb 20 18:15:17.278621 Error: aggregator: (unix:replicator): net_connect_unix(replicator) failed: Permission denied

Manually chmoding the socket to 0666 after starting dovecot seemed to get replication into a working state, but as mentioned, I doubt that is a secure configuration.

To solve this, I figured I would create a group dovecot-replicator-user, put marcel (and others) in that group and use this piece of configuration:

service replicator {
 unix_listener replicator-doveadm {
 # This was for testing only
 mode = 0666
 user = root
 }
 # Newly added bit:
 unix_listener replicator {
 mode = 0660
 user = root
 group = dovecot-replicator-user
 }
}

Upon starting, I see the expected permissions on the socket:

srw-rw---- 1 root dovecot-replicator-user 0 Feb 20 19:30 replicator

This brings back the original error in the logs. Manually chmodding to 0666 once again restores functionality.
I guess I don't understand the communication patterns used. Which process tries to connect to this replicator socket?

Full configuration:

dsync_remote_cmd = ssh %{host} doveadm dsync-server -u%{user}
mail_replica = remote:root@<<redacted>>
replication_max_conns = 2
mail_plugins {
 notify = yes
 replication = yes
}
service replicator {
 process_min_avail = 1
}
service aggregator {
 fifo_listener replication-notify-fifo {
 mode = 0666
 user = root
 }
 unix_listener replication-notify {
 mode = 0666
 user = root
 }
}
service replicator {
 unix_listener replicator-doveadm {
 mode = 0666
 user = root
 }
 unix_listener replicator {
 mode = 0660
 user = root
 group = dovecot-replicator-user
 }
}

I've just started using Wormhole for my small scale mail system. I had already upgraded from dovecot 2.3 a while ago and just put a cron job with periodic sync for the time being. Anyway, I'm struggling to understand the unix socket permissions. I'm using mostly Debian 13 defaults. The dovecot/imap process is running as the mail user (in this case marcel). Other processes run as dovecot/dovenull and some as root: ``` # ps -Af | grep dovecot root 2669191 2669190 0 19:13 ? 00:00:00 dovecot/anvil root 2669192 2669190 0 19:13 ? 00:00:00 dovecot/replicator root 2669193 2669190 0 19:13 ? 00:00:00 dovecot/log root 2669194 2669190 0 19:13 ? 00:00:00 dovecot/config dovecot 2669195 2669190 0 19:13 ? 00:00:00 dovecot/stats dovecot 2669196 2669190 0 19:13 ? 00:00:00 dovecot/auth dovenull 2669227 2669190 0 19:13 ? 00:00:00 dovecot/imap-login marcel 2669327 2669190 0 19:15 ? 00:00:00 dovecot/imap root 2669328 2669190 0 19:15 ? 00:00:00 dovecot/auth -w ``` The issue I'm having is with the permissions for the unix socket `/run/dovecot/replicator`. Its permissions seem to default to root:root and 0666. https://codeberg.org/errror/wormhole/src/branch/main/doc/replication.md mentions that 0666 permissions are okay'ish for `replication-notify`, but I doubt this is the case for this particular socket. Using an adapted sample configuration, the replication is not working and these errors are logged every time there is something to sync: ``` Feb 20 18:15:17.278621 Error: aggregator: (unix:replicator): net_connect_unix(replicator) failed: Permission denied ``` Manually `chmod`ing the socket to 0666 after starting dovecot seemed to get replication into a working state, but as mentioned, I doubt that is a secure configuration. To solve this, I figured I would create a group `dovecot-replicator-user`, put `marcel` (and others) in that group and use this piece of configuration: ``` service replicator { unix_listener replicator-doveadm { # This was for testing only mode = 0666 user = root } # Newly added bit: unix_listener replicator { mode = 0660 user = root group = dovecot-replicator-user } } ``` Upon starting, I see the expected permissions on the socket: ```srw-rw---- 1 root dovecot-replicator-user 0 Feb 20 19:30 replicator``` This brings back the original error in the logs. Manually chmodding to 0666 once again restores functionality. I guess I don't understand the communication patterns used. Which process tries to connect to this `replicator` socket? Full configuration: ``` dsync_remote_cmd = ssh %{host} doveadm dsync-server -u%{user} mail_replica = remote:root@<<redacted>> replication_max_conns = 2 mail_plugins { notify = yes replication = yes } service replicator { process_min_avail = 1 } service aggregator { fifo_listener replication-notify-fifo { mode = 0666 user = root } unix_listener replication-notify { mode = 0666 user = root } } service replicator { unix_listener replicator-doveadm { mode = 0666 user = root } unix_listener replicator { mode = 0660 user = root group = dovecot-replicator-user } } ```

errror commented 2026年02月21日 09:22:44 +01:00

Hi @Thorarin ,

thanks for the well detailed report!

You are using posix-mapped mail users, similar to my own setups. From my point of view your problem can solved by setting

service aggregator {
 fifo_listener replication-notify-fifo {
 mode = 0666
 }
 unix_listener replication-notify {
 mode = 0666
 }
}
service replicator {
 process_min_avail = 1
 unix_listener replicator {
 mode = 0666
 }
 unix_listener replicator-doveadm {
 mode = 0666
 }
}

These settings also worked in my 2.2/2.3 setup for years. I know this is possibly a security issue. I currently have addressed this issue with a general policy that users don't have shell access on the IMAP backends.

Does this configuration solves your issue? If not, please also sent the output of doveconf -n with your answer.

How did you solve this issue in your 2.3 setup? Maybe you can provide an (anonymized!) config of your last 2.3 setup with replication?

P.S.: Hardening the above solution and better documentation about it are still on the roadmap for me. An alternative approach might be setting system_groups_user https://doc.dovecot.org/latest/core/config/auth/userdb.html#system-groups-user appropriately. I will need to check this in more detail for the upcoming documentation update.

Hi @Thorarin , thanks for the well detailed report! You are using posix-mapped mail users, similar to my own setups. From my point of view your problem can solved by setting ``` service aggregator { fifo_listener replication-notify-fifo { mode = 0666 } unix_listener replication-notify { mode = 0666 } } service replicator { process_min_avail = 1 unix_listener replicator { mode = 0666 } unix_listener replicator-doveadm { mode = 0666 } } ``` These settings also worked in my 2.2/2.3 setup for years. I know this is possibly a security issue. I currently have addressed this issue with a general policy that users don't have shell access on the IMAP backends. Does this configuration solves your issue? If not, please also sent the output of `doveconf -n` with your answer. How did you solve this issue in your 2.3 setup? Maybe you can provide an (anonymized!) config of your last 2.3 setup with replication? P.S.: Hardening the above solution and better documentation about it are still on the roadmap for me. An alternative approach might be setting `system_groups_user` https://doc.dovecot.org/latest/core/config/auth/userdb.html#system-groups-user appropriately. I will need to check this in more detail for the upcoming documentation update.

Thorarin commented 2026年02月21日 10:23:57 +01:00

I tried that configuration. It indeed works without manual chmoding, but I'm a little worried about the security implications.
In practice, there aren't many users on the system as it's only a home server, but some guidance for hardening would sure be welcome.

My 2.3 config didn't contain any explicit configuration for unix_listener replicator, from what I can tell.

I tried that configuration. It indeed works without manual `chmod`ing, but I'm a little worried about the security implications. In practice, there aren't many users on the system as it's only a home server, but some guidance for hardening would sure be welcome. My 2.3 config didn't contain any explicit configuration for `unix_listener replicator`, from what I can tell.

errror commented 2026年02月24日 13:50:50 +01:00

Update: I am currently reviewing the defaults for service replicator and service aggregator. The review aims in simplifying the configuration as well as considering security issues.
If there are now new issues or regressions, the next release will include the results of this review.

Update: I am currently reviewing the defaults for `service replicator` and `service aggregator`. The review aims in simplifying the configuration as well as considering security issues. If there are now new issues or regressions, the next release will include the results of this review.