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.
- There was a similar issue two months ago: https://github.com/docker-mailserver/docker-mailserver/issues/3665
- This time, however, the check seems to work correctly and the private key files are actually owned by the wrong group/user (
dovenull
).
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 byamavis
before. amavis
has110:112
which was used bydovecot
before.dovecot
has111:113
which was used bydovenull
before.- And finally,
dovenull
is using112:114
– the UID/GID pair that belonged torspamd
in DMS 13.2.0. Apparently, that’s why userdovenull
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
- Generate DKIM keys with DMS <13.3.0 (Rspamd enabled)
- Update DMS to 13.3.0 and start it
- 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)
@georglauterbach
I see there is an update today, which the changelog says:
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 😃/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 asroot
).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 rundocker 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:
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 haverspamd/local.d/multimap.conf
which adds a couple local domain-based maps (for whitelist and blacklist overrides) stored inrspamd/local-maps/LOCAL_WL_FROM_DOMAIN.map
andrspamd/local-maps/LOCAL_BL_FROM_DOMAIN.map
. In doing so I can quickly edit those lists via the RSPAMd Web UI “configuration” page. Myrspamd/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.