> > Every few weeks I'll start seeing this error: > > > > ERROR: clam database directory (clam_dbs) not writable /var/lib/clamav > > ... > > -rw-r--r-- 1 clamupdate clamupdate 296388 Sep 19 2019 bytecode.cvd > > -rw-r--r-- 1 clamupdate clamupdate 112832258 Sep 17 09:53 daily.cvd > > -rw-r--r-- 1 clamupdate clamupdate 117859675 Nov 25 2019 main.cvd > > ... > > I've tried grepping for the clamupdate user in all the .conf files and > > anywhere it appears it's commented out. Any other places to look? > > It's a little bit concerning because if something is changing ownership > of the files then (a) it looks like it's running with root permissions > and (b) you don't know what it is. > > Are you sure that you don't have something else running which sets the > permissions?
That's what I'm trying to figure out. I've looked through the crontab files, e.g., in /etc/conf*, bubcus > Are there logs going back far enough to give you a good > feel for exactly when it happens? I believe so and I have access to the backups which go back at least a year. That's why I pointed to this log: /var/log/clamav-unofficial-sigs/clamav-unofficial-sigs.log And today when it started: Oct 09 04:15:56 Checking for urlhaus updates... Oct 09 04:15:56 Checking for updated urlhaus database file: urlhaus.ndb Oct 09 04:15:56 Testing updated urlhaus database file: urlhaus.ndb Oct 09 04:15:56 Clamscan reports urlhaus urlhaus.ndb database integrity tested good Oct 09 04:15:56 Successfully updated urlhaus production database file: urlhaus.ndb Oct 09 04:15:56 Update(s) detected, reloading ClamAV databases Oct 09 04:15:56 ClamAV databases reloading Oct 09 04:15:56 Issue tracker : https://github.com/extremeshok/clamav-unofficial-sigs/issues Oct 09 04:15:56 Powered By https://eXtremeSHOK.com *Oct 09 05:14:02 ERROR: clam database directory (clam_dbs) not writable /var/lib/clamav* So between 4:15 and 5:15 AM today (EDT). If it were my problem I'd probably > start with some simple logging so it was more clear what happened when; > something like a cron job which just makes a listing of the permissions > every minute, appending it to a file in /var/log. 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 > I'll consider this too, perhaps I should contact the ExtremeSHOK contributors at https://github.com/extremeshok/clamav-unofficial-sigs? Or perhaps there's some debug option that I'm not aware of? In /etc/clamav-unofficial-sigs/master.conf I have: logging_enabled="yes" log_file_path="/var/log/clamav-unofficial-sigs" log_file_name="clamav-unofficial-sigs.log" > If you just want to paper over the cracks you could for example make a > wrapper for the update script which sets permissions before running it, > or run another script before invocations of the update script so that > the permissions are set first, or hack the update script itself. You > could even use 'chattr' to make the permissions unchangeable. > Yeah I've used the chattr option in other areas, perhaps some logging would appear if I take this approach. Later on Fri, 9 Oct 2020, Robert Kudyba wrote: > > > The only reference to clamupdate I see are in the various config > > files, e.g., clamav.conf ... > > I'm puzzled. Why is there a reference to the 'clamupdate' user in a > file called 'clamav.conf' (which I take to be a bowdlerized version of > something like clamd.conf) if you don't use the 'clamupdate' user ID? > Sure looks like earlier versions of Fedora did this according to this bug report <https://bugzilla.redhat.com/show_bug.cgi?id=963920> and this discussion <https://lists.fedoraproject.org/pipermail/test/2013-May/115552.html> on Fedora Project. Ha bowdlerized <https://www.google.com/search?q=bowdlerized&rlz=1C1CHBF_enUS796US796&oq=bow&aqs=chrome.0.69i59j69i57j0l5j69i60.952j1j4&sourceid=chrome&ie=UTF-8>: (of a text or account) having had material considered improper or offensive removed. > It makes me wonder if there have been changes from some original setup > which did employ that user and which haven't all been flushed through, > or if something else has modified the ClamAV configuration files that > you don't know about. > I believe I configured and installed it myself less than 2 years ago but perhaps when I restored some files from a backup I added some old config files and or/services? I do see: systemctl status clam clamav-clamonacc.service clamav-unofficial-sigs.service clamd.service clamav-freshclam.service clamav-unofficial-sigs.timer clam-freshclam.service clamav-milter.service clamd@scan.service clamonacc.service Only clamav-milter, clamd@scan.service and clamav-freshclam.service are active. Years ago I had trouble with the forerunner to the extremeshock script > which resulted in execute bits from scripts getting lost, but that's a > bit different from what you're seeing and it was over a decade ago. I > spent some time with Bill Landry who wrote the original and eventually > we got it fixed. I only mention it because this is eerily similar. Yes very well could be as the extra config files (that start with os.*) from ExtremeSHOK don't mention Fedora, just CentOS and perhaps there is something unique to Fedora. I believe when I was testing I may have tried to use the clamupdate user as I see these are commented out: grep clamupdate /etc/clamav-unofficial-sigs/* /etc/clamav-unofficial-sigs/os.conf:#clam_user="clamupdate" /etc/clamav-unofficial-sigs/os.conf:#clam_group="clamupdate" I see Fangfrisch <https://rseichter.github.io/fangfrisch/>is being maintained as an alternative. Haven't tried it yet.
_______________________________________________ clamav-users mailing list clamav-users@lists.clamav.net 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
