> > >> ... next time it happens I can try some of these: > >>> ... > >> > >> ... put some logging in place before it does, so you get as precise a > >> timeline as you can. > > > > Indeed and here we are 9 months later and the problem is back. I can see > > this happened after Jul 3 at 4:22 AM: > > ... > > Jul 03 05:14:01 ERROR: clam database directory (clam_dbs) not writable > /var/lib/clamav > > Where's the log of the permissions, listed every minute, which I > suggested to you back in October?! >
I did proffer the -i option: su - clamav -s /bin/bash -c '/usr/local/sbin/clamav-unofficial-sigs.sh -i' ################################################################################ eXtremeSHOK.com ClamAV Unofficial Signature Updater Version: v7.2.5 (2021-03-20) Required Configuration Version: v96 Copyright (c) Adrian Jon Kriel :: [email protected] ################################################################################ Loading config: /etc/clamav-unofficial-sigs/master.conf Loading config: /etc/clamav-unofficial-sigs/os.conf Loading config: /etc/clamav-unofficial-sigs/user.conf *** SCRIPT INFORMATION *** clamav-unofficial-sigs.sh 7.2.5 (2021-03-20) Master.conf Version: 97 Minimum required config: 96 *** SYSTEM INFORMATION *** Linux storm.cis.fordham.edu 5.12.12-200.fc33.x86_64 #1 SMP Fri Jun 18 14:28:47 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux *** CLAMSCAN LOCATION & VERSION *** /usr/bin/clamscan ClamAV 0.103.3/26228/Sun Jul 11 07:05:30 2021 *** RSYNC LOCATION & VERSION *** /usr/bin/rsync rsync version 3.2.3 protocol version 31 *** CURL LOCATION & VERSION *** /usr/bin/curl curl 7.71.1 (x86_64-redhat-linux-gnu) libcurl/7.71.1 OpenSSL/1.1.1k-fips zlib/1.2.11 brotli/1.0.9 libidn2/2.3.1 libpsl/0.21.1 (+libidn2/2.3.0) libssh/0.9.5/openssl/zlib nghttp2/1.43.0 *** GPG LOCATION & VERSION *** /usr/bin/gpg gpg (GnuPG) 2.2.25 *** DIRECTORY INFORMATION *** Working Directory: /var/lib/clamav-unofficial-sigs Clam Database Directory: /var/lib/clamav Configuration Directory: /etc/clamav-unofficial-sigs The suggestion you gave me previously: >* It's just a shell script, you could edit it to put debugging things in *>* there if you're comfortable with hacking shell scripts. Does it give *>* usage help if run with no arguments?* I guess the answer is I'm not comfortable with hacking the shell script. > > On Fri, 9 Oct 2020, G.W. Haywood wrote: > |> ...start with some simple logging [...] Something like this > |> in a crontab: > |> > |> * * * * * /bin/echo -n "$(/bin/date) " >> /var/log/clam_perms.log ; \ > |> /bin/ls -l /var/lib/clamav >> /var/log/clam_perms.log > OK just set this in cron but I suppose it isn't useful until the problem happens again. On Sun, 11 Jul 2021, Robert Kudyba wrote: > > ls -ld /var/lib/clamav > > > > drwxr-xr-x. 4 clamupdate clamupdate 8192 Jul 3 04:46 */var/lib/clamav* > > The 'dot' after the directory permissions probably means that SELinux > or similar is involved. If so, it might have been good to mention it > earlier. Have you made sure that there's no other access control than > the file and directory permissions which you've been showing us? > SELinux definitely disabled this entire time. sestatus SELinux status: disabled ls -ald /var/lib/clamav drwxrwxr-x. 4 clamav clamav 8192 Jul 12 08:23 /var/lib/clamav ls -Zd /var/lib/clamav system_u:object_r:antivirus_db_t:s0 /var/lib/clamav > If you made the permissions > > drwxrwxr-x > > instead, you could probably forget about it - but again it might be to > paper over a crack. OK so some variation of setfattr -h -x security.selinux > Another thought, do you have the 'setgid' bit set on one of the parent > directories? > Running find /var/lib/ -perm /6000 -type f results in only some Docker containers > > > ... these 3 files have their owner changed but note the old date > timestamp: > > > > -rw-r--r-- 1 clamupdate clamupdate 293670 Apr 8 06:32 bytecode.cvd > > > > -rw-r--r-- 1 clamupdate clamupdate 107169718 Jun 22 18:06 daily.cvd > > > > -rw-r--r-- 1 clamupdate clamupdate 117859675 Nov 25 2019 main.cvd > > If it's only these files which are getting the wrong UID/GID then it > sort of implicates whatever is running freshclam, since that's likely > to be the thing which modifies only those files. ps -auwx|grep fresh clamav 3930506 0.0 0.0 103116 16108 ? Ss Jul11 0:05 /usr/bin/freshclam -d --foreground=true > But I'd still want to see that log. > The log from the cronjob, freshclam or eXtremeSHOK.com ClamAV Unofficial Signature Updater? > > grep 985 /etc/passwd > > > > clamav:x:*985*:981::/var/run/clamav:/sbin/nologin > > I guess that group 981 is the GID of the 'clamupdate' group? > grep 981 /etc/group clamav:x:981:clamscan,clamilt,clamupdate
_______________________________________________ clamav-users mailing list [email protected] https://lists.clamav.net/mailman/listinfo/clamav-users Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
