Bug 1473017 - amavisd-new-2.11.0-1 has issue with DCC, can't write to /etc/dcc
Summary: amavisd-new-2.11.0-1 has issue with DCC, can't write to /etc/dcc
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: amavisd-new
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Juan Orti
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-19 20:49 UTC by Peter Bieringer
Modified: 2018-01-08 07:03 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-07 10:25:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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


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