Description of problem: When setting the parameters: MilterSocketMode 660 MilterSocketGroup postfix at /etc/clamav-milter.conf then clamav-milter will log errors that the group can't changed. Version-Release number of selected component (if applicable): clamav-milter-0.98.3-1.el6.x86_64 How reproducible: every time Steps to Reproduce: 1. put the parameter in the config file 2. service clamav-milter restart Actual results: socket without rights an the error: clamav-milter[13858]: Failed to change socket ownership to group postfix Expected results: working socket
I'd like to confirm this bug with CentOS 7 and the latest clamav-milter package (clamav-milter-0.98.7-1.el7.x86_64). Apparently, clamav-milter drops root priviledges too early, thus the configuration parameter MilterSocketGroup is useless, since when it tries to set group ownership the process hasn't got access to do so. In Debian, there was a workaround, which used /etc/default/clamav-milter and setting the variable SOCKET_RWGROUP. This allowed the process to set group permissions early enough. Unfortunately, this workaround does not work with CentOS 7 supplied clamav-milter RPM package. The only solution, is to permanently run clamav-milter as root (User root), and when the process tries to set group permissions it will be able to set them. Unfortunately, this leaves a security risk because the clamav-milter process will be running as root. It is important to run as postfix group, in order for the entire chain workflow to communicate via local sockets without root priviledges: postfix (postfix/postfix) -> clamav-milter (clamilt/postfix) -> clamd (clamilt,clamilt) I hope the above analysis is of help. PS: The Debian discussion from 2011 is here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636877
Dimitris, can you please test clamav-0.99-2.el7, which is still in testing repository? It breaks SELinux, but might address the rest.
I just tested it, with SELinux 'enabled' and 'permissive' modes and in both cases it failed to change group ownership. systemd: Started Milter module for the Clam Antivirus scanner. systemd: Starting Milter module for the Clam Antivirus scanner... clamav-milter: ERROR: Failed to change socket ownership to group postfix systemd: clamav-milter.service: main process exited, code=exited, status=1/FAILURE systemd: Unit clamav-milter.service entered failed state. systemd: clamav-milter.service failed. systemd: clamav-milter.service holdoff time over, scheduling restart. ● clamav-milter.service - Milter module for the Clam Antivirus scanner Loaded: loaded (/usr/lib/systemd/system/clamav-milter.service; enabled; vendor preset: disabled) Active: failed (Result: start-limit) since Wed 2016-01-20 01:46:20 EET; 5s ago Process: 2621 ExecStart=/usr/sbin/clamav-milter -c /etc/mail/clamav-milter.conf --nofork=yes (code=exited, status=1/FAILURE) Main PID: 2621 (code=exited, status=1/FAILURE) The updated packages (excluding clamav itself) clamav-milter x86_64 0.99-2.el7 epel-testing 96 k clamav-milter-systemd noarch 0.99-2.el7 epel-testing 20 k clamav-milter-sysvinit noarch 0.99-2.el7 epel-testing 20 k
Debian also had the same problem, but it seems like there is a patch that allows clamav-milter to set ownership before dropping privileges. Bug report with patch here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636881
So it seems this is still an issue.... I'm coming across this right now... clamav-milter-0.99.2-1.el7.x86_64 clamav-milter-systemd-0.99.2-1.el7.noarch
Steven, sorry you hit the same bug as I have. Based on my experience (https://bugzilla.redhat.com/show_bug.cgi?id=1305746), it seems there isn't much incentive to fix these bugs. EPEL is a community effort, so maybe the maintainers have moved on to other projects? Anyway, regarding this bug, I've been forced to by-pass it, by doing this horrible workaround: - disable auto-starting of clamav-milter: systemctl disable clamav-milter - in /etc/rc.local add: rm -rf /run/clamav-milter/clamav-milter.socket && systemctl start clamav-milter - make /etc/rc.local executable chmod +x /etc/rc.local - safely reboot In CentOS 7.x you need to make /etc/rc.local executable, otherwise it will be ignored on boot. The above procedure manually erases the socket and starts clamav-milter right after, so you never hit the bug.
Ok, as this is probably abandonware type status, I fixed this in systemd by making a custom unit file. I've included this below. [Unit] Description = Milter module for the Clam Antivirus scanner After = syslog.target nss-lookup.target network.target Before = sendmail.service Before = postfix.service [Service] Type = simple ExecStart = /usr/sbin/clamav-milter -c /etc/mail/clamav-milter.conf --foreground=yes ExecStartPost= /bin/sh -c 'while [ ! -S /var/run/clamav-milter/clamav-milter.socket ]; do sleep 1; done; /bin/chgrp postfix /var/run/clamav-milter /var/run/clamav-milter/clamav-milter.socket' Restart = on-failure User=clamilt Group=clamilt PermissionsStartOnly=true PrivateTmp=yes PrivateDevices=yes NoNewPrivileges=yes CapabilityBoundingSet=CAP_KILL ReadOnlyDirectories=/etc ReadOnlyDirectories=/usr ReadOnlyDirectories=/var/lib [Install] WantedBy = multi-user.target
That being said, this would be ideally fixed in the clamav-milter via the patch previously referenced....
According to https://bugzilla.clamav.net/show_bug.cgi?id=10731, the referenced patch from the Debian bug report is upstream since ClamAV 0.98.8.
Well, the bug is reproducible, so its not my imagination. I forgot to mention that I've got SELinux enabled in enforcing mode, not sure if that is relevant.
I personally do not use clamav-milter, thus: Could you please provide the absolute minimum steps to reproduce this issue?
Sure. I've tried the following steps on a brand new CentOS 7.3 minimal install (virtualbox) - install centos minimal - login as root - yum update - yum install epel-release - yum install clamav-milter-systemd - edit /etc/mail/clamav-milter.conf and enable these lines only (and comment out the Example line): MilterSocket /var/run/clamav-milter/clamav-milter.socket MilterSocketGroup postfix MilterSocketMode 660 User clamilt AllowSupplementaryGroups yes LogSyslog yes - systemctl enable clamav-milter - systemctl start clamav-milter - ls -la /var/run/clamav-milter/clamav-milter.socket correct ownership should be: clamilt:postfix wrong ownership is: clamilt:clamilt also look at /var/log/messages for the following error: Failed to change socket ownership to group postfix
Okay, and why can't the postfix user be added to the clamilt group?
Well, that wouldn't be a fix for the bug, but just a by-pass?
Hello I think I fix this bug in clamav-0.100.1-3.el7 [1] /var/run/clamav-milter/ now have group ownership virusgroup and is one group of clamilt [1] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ecad18a061
I forgot about SELinux I added to clamd-README that we need run: setsebool -P antivirus_can_scan_system 1 and also maybe this one (I need to confirm that is obsolete) setsebool -P antivirus_use_jit 1 restorecon -R -v "/var/run/clamd.<SERVICE>"
https://bugzilla.redhat.com/show_bug.cgi?id=1105888#c9 says that bug was fixed upstream in 0.98.8 After that, clamilt is in the group of virusgroup and since clamav-0.100.1-3 [2] we got [1], with SELinux instruction in previous comment, clamav-milter works out of the box , so I'm closing this bug as fixed in next release, if not please reopen it and explain what is not working . Thanks. [1] cat /usr/lib/tmpfiles.d/clamd.scan.conf d /run/clamd.scan 0710 clamscan virusgroup cat /usr/lib/tmpfiles.d/clamav-milter.conf d /run/clamav-milter 0710 clamilt clamilt [2] https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-ecad18a061 https://bodhi.fedoraproject.org/updates/FEDORA-2018-61b6e4545f https://bodhi.fedoraproject.org/updates/FEDORA-2018-c1c78a6e35