https://bugzilla.redhat.com/show_bug.cgi?id=1473017
Bug ID: 1473017 Summary: amavisd-new-2.11.0-1 has issue with DCC, can't write to /etc/dcc Product: Fedora EPEL Version: epel7 Component: amavisd-new Severity: low Assignee: j.orti.alcaine@gmail.com Reporter: pb@bieringer.de QA Contact: extras-qa@fedoraproject.org CC: janfrode@tanso.net, j.orti.alcaine@gmail.com, perl-devel@lists.fedoraproject.org, steve@silug.org, vanmeeuwen+fedora@kolabsys.com
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
https://bugzilla.redhat.com/show_bug.cgi?id=1473017
Juan Orti j.orti.alcaine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pb@bieringer.de Flags| |needinfo?(pb@bieringer.de)
--- Comment #1 from Juan Orti j.orti.alcaine@gmail.com --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=1473017
Peter Bieringer pb@bieringer.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(pb@bieringer.de) |
--- Comment #2 from Peter Bieringer pb@bieringer.de --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1473017
--- Comment #3 from Peter Bieringer pb@bieringer.de --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=1473017
--- Comment #4 from Juan Orti j.orti.alcaine@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=1473017
Juan Orti j.orti.alcaine@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution|--- |NOTABUG Last Closed| |2017-08-07 06:25:31
https://bugzilla.redhat.com/show_bug.cgi?id=1473017
--- Comment #5 from Peter Bieringer pb@bieringer.de --- 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
perl-devel@lists.fedoraproject.org