docker-mailserver: bug report: existing rspamd DKIM private key files are owned by dovenull instead of _rspamd user

📝 Preliminary Checks

  • I tried searching for an existing issue and followed the debugging docs advice, but still need assistance.

👀 What Happened?

After updating DMS from 13.2.0 to 13.3.0 I get a warning at startup that the DKIM private key files would not have the correct permissions.

The bug seems to be related with https://github.com/docker-mailserver/docker-mailserver/commit/e3331b0f44b1d9c1c513389ad5b6f3b09e51dc16

If we look at /etc/passwd in DMS v13.3.0, we notice that:

  • the new user _mta-sts has UID 109 and GID 111, which was used by amavis before.
  • amavis has 110:112 which was used by dovecot before.
  • dovecot has 111:113 which was used by dovenull before.
  • And finally, dovenull is using 112:114 – the UID/GID pair that belonged to rspamd in DMS 13.2.0. Apparently, that’s why user dovenull now has control over our DKIM private files.
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
clamav:x:200:200::/var/lib/clamav:/usr/sbin/nologin
postfix:x:101:102::/var/spool/postfix:/usr/sbin/nologin
fetchmail:x:102:65534::/var/lib/fetchmail:/bin/false
postsrsd:x:103:104::/var/lib/postsrsd:/usr/sbin/nologin
opendkim:x:104:106::/run/opendkim:/usr/sbin/nologin
opendmarc:x:105:107::/run/opendmarc:/usr/sbin/nologin
postgrey:x:106:108::/var/lib/postgrey:/usr/sbin/nologin
policyd-spf:x:107:109::/nonexistent:/usr/sbin/nologin
debian-spamd:x:108:110::/var/lib/spamassassin:/usr/sbin/nologin
_mta-sts:x:109:111::/var/lib/mta-sts/:/usr/sbin/nologin
amavis:x:110:112:AMaViS system user,,,:/var/lib/amavis:/bin/sh
dovecot:x:111:113:Dovecot mail server,,,:/usr/lib/dovecot:/usr/sbin/nologin
dovenull:x:112:114:Dovecot login user,,,:/nonexistent:/usr/sbin/nologin
_rspamd:x:113:115:rspamd spam filtering system,,,:/var/lib/rspamd:/usr/sbin/nologin
redis:x:114:116::/var/lib/redis:/usr/sbin/nologin
syslog:x:115:65534::/home/syslog:/usr/sbin/nologin
docker:x:5000:5000::/home/docker:/bin/bash

Changing permissions manually seems to fix the problem by running:

docker exec -ti mailserver sh -c 'chown _rspamd:_rspamd /tmp/docker-mailserver/rspamd/dkim \
  && chown _rspamd:_rspamd /tmp/docker-mailserver/rspamd/dkim/*.private.txt'`

Adding the chown command to the Rspamd startup script should fix this issue without requiring manual intervention. But it would break backward compatibility, too. Maybe there is an opportunity to set _mta-sts’s UID/GID to a fixed (higher) value so that amavis, dovecot, dovenull and _rspamd can keep their “original” (G)UIDs?

(Feel free to correct me – it’s my first bug report and I have to admit that I only understand half of what I write here 😄 )

👟 Reproduction Steps

  1. Generate DKIM keys with DMS <13.3.0 (Rspamd enabled)
  2. Update DMS to 13.3.0 and start it
  3. Check container logs – and verify wrong permissions with docker exec -ti mailserver ls -la /tmp/docker-mailserver/rspamd/dkim
drwxr-xr-x 2 dovenull dovenull 4096 Jan 21 16:05 .
drwxr-xr-x 4 root    root    4096 Jan 21 16:05 ..
-rw------- 1 dovenull dovenull 1675 Jan 21 16:05 rsa-2048-mail-example.com.private.txt
-rw-r--r-- 1 root    root     411 Jan 21 16:05 rsa-2048-mail-example.com.public.dns.txt
-rw-r--r-- 1 root    root     451 Jan 21 16:05 rsa-2048-mail-example.com.public.txt

🐋 DMS Version

v13.3.0

💻 Operating System and Architecture

Fedora CoreOS 39 x86_64 (running Podman – but also tested with Docker on Debian x86_64)

⚙️ Container configuration files

No response

📜 Relevant log output

[ WARNING ]  (Rspamd setup) Rspamd DKIM private key file '/tmp/docker-mailserver/rspamd/dkim/rsa-2048-mail-example.com.private.txt' does not appear to have correct permissions/ownership for Rspamd to use it

About this issue

  • Original URL
  • State: closed
  • Created 5 months ago
  • Reactions: 4
  • Comments: 16 (9 by maintainers)

Most upvoted comments

@georglauterbach

I see there is an update today, which the changelog says:

Rspamd: We now ensure correct ownership (_rspamd:_rspamd) for the Rspamd DKIM directory and files (/tmp/docker-mailserver/rspamd/dkim/)

However, I’m still getting the same errors in the docker logs, after pulling the latest image and restarting.


EDIT - alright, looks like docker-compose down && docker-compose up -d resolved it 😃

but what would you suggest for the custom map files it references (which I have in /tmp/docker-mailserver/rspamd/local-maps/ currently) as far as potential permission changes between versions.

/tmp/docker-mailserver isn’t really meant to be concerned with permissions. It is just a location for users to provide config and where some of our scripts that generate / update config there (setup ..., typically as root).

Anything where permissions matter internally is something that should only be an issue with custom files being directly mounted / referenced when there is no /tmp/docker-mailserver to internal copy + ownership support available.

When that ownership is a user / group DMS manages, that is planned in a future release to become static across releases so you will eventually not have the issue, but for now you will need to make sure it’s correct across releases.

Since this kind of issue should not happen too often, I think using chown manually here is the best course of action for now @Codelica

@polarathene I see my custom RSPAMd config from /tmp/docker-mailserver/rspamd/local.d/ gets copied into /etc/rspamd/local.d/ so it shouldn’t be a concern, but what would you suggest for the custom map files it references (which I have in /tmp/docker-mailserver/rspamd/local-maps/ currently) as far as potential permission changes between versions. I can definitely run docker exec mailserver chown -R _rspamd:_rspamd /tmp/docker-mailserver/rspamd/local-maps but just curious if I’m missing a “better” or more supported solution.

Downgrading (“backwards-compatibility” is not the same IMO) is not a supported path with DMS; so we need not to worry about it.

@polarathene re:

For example I have some custom local maps

Can you provide more context?

Sorry for the late reply here, life got complicated yesterday. As far as my use for a couple custon local maps in RSPAMd, keep in mind I’m definitely still new to the project, so I could easly be doing this the wrong way. 😉

Basically I have /tmp/docker-mailserver/ bind mounted to a local directory for config, in which I have rspamd/local.d/multimap.conf which adds a couple local domain-based maps (for whitelist and blacklist overrides) stored in rspamd/local-maps/LOCAL_WL_FROM_DOMAIN.map and rspamd/local-maps/LOCAL_BL_FROM_DOMAIN.map. In doing so I can quickly edit those lists via the RSPAMd Web UI “configuration” page. My rspamd/local-maps directory and the maps inside it are _rspamd:_rspamd owned, but I don’t remember off-hand if I set that to allow editing or if it was the result of the RSPAMd Web UI being used for edits.