We use CentOS 5 here and recently ran across this issue with ClamAV
0.95.3 (we're using the clamav-0.95.3-46.el5 RPM from either RPMForge or
ATRPMs). The startup script in that RPM is still written for ClamAV
prior to 0.95 where clamav-milter did not use a configuration file.
The old script uses the following code to look at CLAMAV_MILTER in
/etc/sysconfig/clamav.
if [ "$CLAMAV_MILTER" == "yes" ] ; then
echo -n $"Starting clamav-milter: "
daemon clamav-milter --config-file=/etc/clamd.conf \
--max-children=10 \
--force-scan \
--quiet \
--noreject \
--outgoing \
--local \
local:/var/run/clamav/clmilter.socket
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/clamav-milter
fi
Which we've modified on our servers to look like (very small change):
if [ "$CLAMAV_MILTER" == "yes" ] ; then
echo -n $"Starting clamav-milter: "
daemon /usr/sbin/clamav-milter
chmod g+w /var/run/clamav/clamav-milter.socket
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/clamav-milter
fi
The problem is that the permissions on the socket file were not being
set correctly to be in the clamav group. Which is why I added the chmod
line. We also had to do a bit of audit2allow in order to get postfix to
talk to the socket (SELinux issues). We added the postfix user to the
clamav group (which I hope is not a huge security risk).
The questions I have are:
1) How do I pass this up the chain to the person who is creating the
RPMs for Red Hat / CentOS?
2) Should we have to manually set the group write attribute in the
startup script? Or should that have been set by clamav-milter if
AllowSupplementaryGroups is set to "yes" in the milter's configuration file?
3) We had to manually clean up the clamav-milter.pid file in the stop()
section of the script.
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/clamav-milter
[ $RETVAL -eq 0 ] && rm -f /var/run/clamav/clamav-milter.pid
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://www.clamav.net/support/ml
