Bug 1473017

Summary: amavisd-new-2.11.0-1 has issue with DCC, can't write to /etc/dcc
Product: [Fedora] Fedora EPEL Reporter: Peter Bieringer <pb>
Component: amavisd-newAssignee: Juan Orti <jorti>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: epel7CC: janfrode, jorti, pb, perl-devel, steve, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-07 10:25:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Peter Bieringer 2017-07-19 20:49:36 UTC 
Description of problem:
since upgrading EL7 system strange DCC messages are occuring.

Version-Release number of selected component (if applicable):
amavisd-new-2.11.0-1 

How reproducible:
always

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:
ProtectSystem=full

This prevents dccproc from writing to /etc/dcc


"Workaround": reduce restriction to

ProtectSystem=true


Looks like systemd.exec is missing a feature, because 

ReadWritePaths=-/etc/dcc

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 06:23:46 UTC 
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 19:08:22 UTC 
I'm currently using DCC-1.3.145-25.el7.x86_64 from ATrpms

It contains

$ rpm -ql DCC | grep ^/etc
/etc/dcc
/etc/dcc/dcc_conf
/etc/dcc/flod
/etc/dcc/grey_flod
/etc/dcc/grey_whitelist
/etc/dcc/ids
/etc/dcc/log
/etc/dcc/map
/etc/dcc/map.txt
/etc/dcc/whiteclnt
/etc/dcc/whitecommon
/etc/dcc/whitelist

and is used by amavis via spamassassin

/usr/share/perl5/vendor_perl/Mail/SpamAssassin/Plugin/DCC.pm
spamassassin-3.4.0-2.el7.x86_64

which get it's configuration from
/etc/mail/spamassassin/local.cf

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 19:54:23 UTC 
btw. RPM packaging layout is the same using dcc from here:

https://updates.atomicorp.com/channels/atomic/centos/7/x86_64/RPMS/
dcc-1.3.158-5.el7.art.x86_64.rpm
Comment 4 Juan Orti 2017-07-20 20:55:50 UTC 
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 07:03:42 UTC 
Just for reference, to change dcc_home to a different location, SpamAssassin/Plugin/DCC.pm need to be extended first:

https://bugzilla.redhat.com/show_bug.cgi?id=1532139