In amavisd-new, current version 2.11.0-r3 (and older versions probably), the systemd-unit prohibits write-access to config-files when spamassassin with DCC-Plugin (mail-filter/dcc-1.3.158) is enabled. Reproducible: Always Steps to Reproduce: 1.every time a mail is filtered with amavisd-new/spamassassin/dcc 2. 3. Actual Results: error: Apr 12 15:38:49 colin dccproc[1484]: open(/var/dcc/map): Read-only file system Expected Results: No error. Log-error: Apr 12 15:38:49 colin dccproc[1484]: open(/var/dcc/map): Read-only file system colin ~ # ll /var/dcc/map lrwxrwxrwx 1 amavis amavis 12 19. Mär 09:36 /var/dcc/map -> /etc/dcc/map mail-filter/dcc-1.3.158 installs its config in /etc/dcc, see ebuild: https://gitweb.gentoo.org/repo/gentoo.git/tree/mail-filter/dcc/dcc-1.3.158.ebuild moveconf() { local into=/etc/dcc/ for i in $@; do mv "${D}${dcc_homedir}/${i}" "${D}${into}" dosym "${into}${i}" "${dcc_homedir}/${i}" done } /usr/lib/systemd/system/amavisd.service includes 'ProtectSystem=full' which disables write-access on /etc by design. # /etc/systemd/system/amavisd.service.d/override.conf [Service] ReadWritePaths=-/etc/dcc will remove the error. Possible solution: mail-filter/dcc should place config in /var/dcc/etc or amavisd's systemd-unit could be changed as above. bug-report on redhat on this topic: https://bugzilla.redhat.com/show_bug.cgi?id=1532139 for the first solution, this patch might be needed. https://bugzilla.redhat.com/show_bug.cgi?id=1532139
I believe we already have the fix for SpamAssassin in place. Reading the source code for "dccproc", it's clear that the map file in question is *not* a configuration file. It's persistent, writable, program data: i.e. the stuff that goes under /var. So I think the right fix for this is to leave the map file (and anything else that needs to be written at runtime) where it is. (/var/lib/dcc would be even better IMO)
I vote to fix this, a gentoo patch for SpamAssassin would be enough to relocate the file under /var afaik. I was today a bit worried when looking briefly on the backup log (changed files) to appear a single /etc/dcc/map entry there when I was not doing any config changes. The contents of the file is binary, and using strings it reveals some funky domain names, none of which I would associate with some public/FOSS service. And the dcc name does not ring a bell either (it was many years I have set up this mail server). So after a little shock that I might have been possibly hacked I found this bug report and got some relief.. but nobody dealt with this yet. Should I try to do this patch myself (rename to ), and you guys then include it when somebody else tests it as well ? My package (afaik latest): mail-filter/dcc-1.3.158-r2::gentoo
on further investigation, the file resides in /etc/dcc/map, yet its a target of the /var/dcc/map symlink: # ls -al /etc/dcc/map -rw------- 1 root root 7700 Jan 20 03:34 /etc/dcc/map # ls -al /var/dcc/map lrwxrwxrwx 1 root root 17 Mar 28 2023 /var/dcc/map -> ../../etc/dcc/map The DCC sources do refer to only /var/dcc folder, not /etc/dcc. So why is the symlink required in the first place? The moveconf() from the ebuild should rather ship the "map" entry and avoid moving and symlinking it. So the fix is adding a condition to dcc-1.3.158.ebuild ?
