[clamav-users] running freshclam and 3rd party/clamav-unofficial-sigs.sh owner name changes occasionally

Fri Oct 9 19:30:45 UTC 2020

>
> 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 at scan.service
 clamonacc.service

Only  clamav-milter, clamd at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clamav.net/pipermail/clamav-users/attachments/20201009/47c44321/attachment.htm>