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
Status: CLOSED NOTABUG
Product: Fedora EPEL
Classification: Fedora
Component: amavisd-new (Show other bugs)
epel7
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Juan Orti
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-19 16:49 EDT by Peter Bieringer
Modified: 2017-08-07 06:25 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-07 06:25:31 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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):
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 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
/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 15:54:23 EDT
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 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.

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