Description of problem: I have just updated clamav as shown in the yum.log Feb 14 16:32:16 Updated: clamav-db-0.97.3-3.el5.x86_64 Feb 14 16:32:18 Updated: clamav-0.97.3-3.el5.x86_64 Feb 14 16:32:19 Updated: clamd-0.97.3-3.el5.x86_64 Feb 14 16:32:19 Updated: clamav-milter-0.97.3-3.el5.x86_64 During the installation it copies the "rpmnew" files into the /etc directory. The new files (as I saw later after logwatch started complaining) contain a new USERID called "clam" when running clamav as another user (which I do), but my configuration files have a username of "clamav". I have been using that username for years and it is suggested on the clamav.org site; it makes sense as it reflects the name of the rpms, the website and the name of the AV system. The updater then added a new user "clam" to /etc/passwd and /etc/group and used THAT UID and GID to change the UID and GID on the directories defined in the current /etc/clamd.conf (and freshclam.conf) file /var/log/clamav/ /var/clamav/ but clamav kept running with the new userid, rendering the clamav system not being able to write database files nor logfiles: [root@piquet /var/lib] #>ls -la clamav/ drwxr-xr-x 4 clam clam 4096 Feb 14 10:34 . drwxr-xr-x 33 root root 4096 Sep 10 22:17 .. -rw-r--r-- 1 clam clam 307200 Feb 10 04:13 bytecode.cld -rw-rw-r-- 1 clam clam 5 Feb 03 20:55 clamav-milter.pid srw-r--r-- 1 clam clam 0 Feb 03 20:55 clamav_milter.sock srw-rw-rw- 1 clam clam 0 Feb 03 20:55 clamd_local.sock -rw-rw-r-- 1 clam clam 5 Feb 03 20:55 clamd.pid -rw-r--r-- 1 clam clam 6241280 Feb 14 04:13 daily.cld drwxr-xr-x 5 clam clam 4096 Feb 14 10:34 lib -rw-r--r-- 1 clam clam 77453824 Oct 12 04:13 main.cld -rw------- 1 clam clam 156 Apr 23 2010 mirrors.dat drwxr-xr-x 2 clam clam 4096 Nov 30 2007 tmp [root@piquet /var/lib] #>grep clam /etc/passwd clamav:x:2201:2201:Clam AntiVirus:/home/clamav:/sbin/nologin clam:x:403:404:Clam Anti Virus Checker:/var/clamav:/sbin/nologin [root@piquet /var/log] #>ps -Afw | /bin/grep -i clam root 12815 12089 0 20:26 pts/1 /bin/grep -i clam clamav 6039 1 0 Feb03 ? /usr/sbin/clamd clamav 6067 1 0 Feb03 ? /usr/sbin/clamav-milter This machine was rebooted on 03.02.12 due to a hardware upgrade, which was done after hours. As you can see, too, that although I restarted clamav after the upgrade it was unable to write to the directories as it was running as "clamav" and the directories permission are set to "clam". Granted, I should have checked, but I have upgraded clamav so many times, everytime successful so I did not check as I expected it to be OK. I have never had any of the clamav updates change the UID and GID of anything nor does it need to and neither should it! This is the first time it happened and it happened on 5 of my CentOS systems, rendering the AV system useless on all of them! If there is already a username defined in the clamd.conf file and the UID/GID of the directories defined in the conf file are reflected on the directories the updater should not touch anything and has never done before. I can understand when a new system is installed to make those changes, but not on a system that has been running successfully finding bugs/viruses/etc for years. The updater, too, puts a file called "freshclam" into /etc/cron.daily with incorrect information that does not reflect at all the current clamd.conf and freshclam.conf: #!/bin/sh ### A simple update script for the clamav virus database. ### This could as well be replaced by a SysV script. ### fix log file if needed LOG_FILE="/var/log/clamav/freshclam.log" if [ ! -f "$LOG_FILE" ]; then touch "$LOG_FILE" chmod 644 "$LOG_FILE" chown clam.clam "$LOG_FILE" fi /usr/bin/freshclam \ --quiet \ --datadir="/var/lib/clamav" \ --log="$LOG_FILE" Hard-coding the database directory is silly (if one is allowed to select its own database directory in the conf files), as it does not reflect at all the configuration of the system. Further I have been running freshclam for years now and the ONLY line that is required in the /etc/cron.d/clamav file is 34 23 * * * clamav /usr/bin/freshclam --quiet freshclam is clever enough to read its configuration from /etc/freshclam.conf, no need to specify a database directory and a username that does not reflect the current configuration of the clamav system/daemon. The only reason why I caught this was logwatch complaining about clamav. Version-Release number of selected component (if applicable): How reproducible: It is reproducible if the username and database directory in the CURRENT conf file is different, but if so it works every time. Steps to Reproduce: 1.update clamav Actual results: UID and GID are changed on the log and database directories to a NEW UID that is not set in the CURRENT clamd.conf and freshclam.conf. It has never ever done this before. Expected results: Leave the configuration settings alone, they have been working for years. If you need to change the permission on the directories READ the settings in the current config file and change accordingly. Additional info: Apache, sendmail, mimedefang, ntp, named and many many more allow me to set my own configuration, the updaters of those daemons never change what I have set. There is no need to specify a new UID when one is already set and neither need the database directories places at a different location. If you read http://www.clamav.net/doc/latest/html/node14.html it specifies the UID to be clamav, leave it as that.
I too have had an on-going nightmare with ClamAV permissions. In my environment, these issues cause our MTAs to stop dead in their tracks every time a redhat update for clamav is published. Each time this update is applied, it screws up the permissions and ownserships, causes clamd to stop and in turn causes exim to stop, with the net-affect of stopping email for 100,000 of my users :-( What I found was this (we use RHEL btw):- clamav package adds the user and group "clamav" clamav update package adds the user and group "clam" Also, clamav uses the directory "/var/clamav" While the update uses the directory "/var/lib/clamav" Also, the permissions in /etc/cron.daily/freshclam are incorrect when compared to the initial install of clamav. This disparity is absolutely bonkers! What i'd ideally like is:- 1) for the red hat packages to actually work as defined on clamav.net's site or 2) Improve checking on freshclam cron job to sanity check updates and chicken out before it breaks things. As a work-around, I have implementd the following script logic within my freshclam script:- # Freshclam configuration extract FRESHCLAM_CONFIG=/etc/freshclam.conf FRESHCLAM_USER=`awk '/^DatabaseOwner/ { print $NF }' $FRESHCLAM_CONFIG` # ClamAV configuration extract (as known to freshclam) CLAMAV_CONFIG=`awk '/^NotifyClamd/ { print $NF }' $FRESHCLAM_CONFIG` CLAMAV_USER=`awk '/^User/ { print $NF }' $CLAMAV_CONFIG` # Derive database destinations FRESHCLAM_DB_DIR=`awk '/^DatabaseDirectory/ { print $NF }' $FRESHCLAM_CONFIG` CLAMAV_DB_DIR=`awk '/^DatabaseDirectory/ { print $NF }' $CLAMAV_CONFIG` # Sanity Check permissions to avoid catastrophe test $FRESHCLAM_USER = $CLAMAV_USER -a $CLAMAV_DB_DIR = $FRESHCLAM_DB_DIR || exit 1 This is to ensure that freshclam *ONLY* runs when both clamd and freshclam are configured to :- 1) run under the same user ID 2) run using the same AV DB directory. 3) Chicken out doing any updates if the configuration doesn't match I'm still awaiting the next clam update to see whether my logic still holds (i'll probably end up with having the script over-written). Regards, Warwick
I think i might have got to the bottom of this...... There are two main sources of clamav - one being EPEL and the other being RPMforge. On my boxes which I inherited, I found that both were at play, but it is unclear which one has the issue. It turns out that the EPEL version uses user 'clam' while the RPMforge version uses user "clamav". See diff below:- # diff -u -r epel-clam/etc/clamd.conf rf-clam/etc/clamd.conf --- epel-clam/etc/clamd.conf 2012-03-08 11:57:07.786780389 +0000 +++ rf-clam/etc/clamd.conf 2012-03-08 11:49:21.289847315 +0000 @@ -66,7 +66,7 @@ # Path to the database directory. # Default: hardcoded (depends on installation options) -DatabaseDirectory /var/lib/clamav +DatabaseDirectory /var/clamav # Only load the official signatures published by the ClamAV project. # Default: no @@ -186,7 +186,7 @@ # Run as another user (clamd must be started by root for this option to work) # Default: don't drop privileges -User clam +User clamav # Initialize supplementary group access (clamd must be started by root). # Default: no And # diff -u -r epel-clam/etc/freshclam.conf rf-clam/etc/freshclam.conf --- epel-clam/etc/freshclam.conf 2012-03-08 11:48:38.593035663 +0000 +++ rf-clam/etc/freshclam.conf 2012-03-08 11:49:20.962848758 +0000 @@ -10,7 +10,7 @@ # Path to the database directory. # WARNING: It must match clamd.conf's directive! # Default: hardcoded (depends on installation options) -DatabaseDirectory /var/lib/clamav +DatabaseDirectory /var/clamav # Path to the log file (make sure it has proper permissions) # Default: disabled @@ -48,7 +48,7 @@ # By default when started freshclam drops privileges and switches to the # "clamav" user. This directive allows you to change the database owner. # Default: clamav (may depend on installation options) -DatabaseOwner clam +DatabaseOwner clamav # Initialize supplementary group access (freshclam must be started by root). # Default: no @@ -118,7 +118,7 @@ # Send the RELOAD command to clamd. # Default: no -#NotifyClamd /path/to/clamd.conf +NotifyClamd /etc/clamd.conf # Run command after successful database update. # Default: disabled Now, when the updates happen (via cron.daily/freshclam):- # diff -u -r epel-clam/etc/cron.daily/freshclam rf-clam/etc/cron.daily/freshclam --- epel-clam/etc/cron.daily/freshclam 2012-03-08 11:48:38.769034887 +0000 +++ rf-clam/etc/cron.daily/freshclam 2012-03-08 11:49:21.034848440 +0000 @@ -3,15 +3,4 @@ ### A simple update script for the clamav virus database. ### This could as well be replaced by a SysV script. -### fix log file if needed -LOG_FILE="/var/log/clamav/freshclam.log" -if [ ! -f "$LOG_FILE" ]; then - touch "$LOG_FILE" - chmod 644 "$LOG_FILE" - chown clam.clam "$LOG_FILE" -fi - -/usr/bin/freshclam \ - --quiet \ - --datadir="/var/lib/clamav" \ - --log="$LOG_FILE" +/usr/bin/freshclam --quiet Viola - what ever you/i did to 'fix the issues' gets undone by freshclam upon next update Now - i've removed all instances of Clam and any trace from /etc /var including users and groups and added the EPEL version afresh. I will update this incident with the outcome of my findings.... Regards, Warwick
I think the issue that is described results from heavy repackaging of ClamAV that already happened earlier than this update (but no other update was applied by the administrator before, otherwise this would have been noticed earlier).
After this heavy rumbling, newer updates should not have introduced such or similar issues again, right? And if so, would you agree to close this RHBZ?
I am closing this report hereby for the time being. From my point of view, the mentioned issues were caused due to ClamAV package rework combined with local RPMforge mixtures. Feel free to reopen this bug report once you have new information. Thank you anyway for reporting this!