Bug 1473017 - amavisd-new-2.11.0-1 has issue with DCC, can't write to /etc/dcc
amavisd-new-2.11.0-1 has issue with DCC, can't write to /etc/dcc
Product: Fedora EPEL
Classification: Fedora
Component: amavisd-new (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Juan Orti
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2017-07-19 16:49 EDT by Peter Bieringer
Modified: 2018-01-08 02:03 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-07 06:25:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Peter Bieringer 2017-07-19 16:49:36 EDT
Description of problem:
since upgrading EL7 system strange DCC messages are occuring.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. have amavisd+spamassassin+DCC installed

Actual results:
Jul 19 22:29:57 *** dccproc[29496]: open(/etc/dcc/map): Permission denied
Jul 19 22:29:57 *** dccproc[29496]: lock_open(/etc/dcc/whiteclnt.dccx): Permission denied; file not writeable for locking

Expected results:
Working as before the update

Additional info:

related systemd unit file changed,

2.11.0-1 added:

This prevents dccproc from writing to /etc/dcc

"Workaround": reduce restriction to


Looks like systemd.exec is missing a feature, because 


is not supported on ProtectSystem=full, only on ProtectSystem=strict (which is even more hard...)

Imho "full" should already honor ReadWritePaths
Comment 1 Juan Orti 2017-07-20 02:23:46 EDT
I don't know DCC, but it shouldn't be writing in /etc, should it? can't you configure it to write its data to /var/dcc or similar?
Comment 2 Peter Bieringer 2017-07-20 15:08:22 EDT
I'm currently using DCC-1.3.145-25.el7.x86_64 from ATrpms

It contains

$ rpm -ql DCC | grep ^/etc

and is used by amavis via spamassassin


which get it's configuration from

which contains currently:

use_dcc 1
dcc_home /etc/dcc
dcc_timeout 10
dcc_add_header 1

=> in principle a change would be possible by changing RPM packaging of DCC to move at least files which are candidates to be modified to /var (and perhaps softlink static files from /etc) and then changing spamassassin's config.
Comment 3 Peter Bieringer 2017-07-20 15:54:23 EDT
btw. RPM packaging layout is the same using dcc from here:

Comment 4 Juan Orti 2017-07-20 16:55:50 EDT
IMHO is wrong to configure dcc with /etc as its data dir.

I disagree to change the current ProtectSystem value. I think it's a good default and the administrator always can override this behaviour.
Comment 5 Peter Bieringer 2018-01-08 02:03:42 EST
Just for reference, to change dcc_home to a different location, SpamAssassin/Plugin/DCC.pm need to be extended first:


Note You need to log in before you can comment on or make changes to this bug.