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

[G.W. Haywood]

Hi there,

On Fri, 9 Oct 2020, Robert Kudyba wrote:

> Running ClamAV 103.0-1 on Fedora, I have freshclam
> and clamav-unofficial-sigs.sh from
> https://github.com/extremeshok/clamav-unofficial-sigs
> ...
> 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?  Are there logs going back far enough to give you a good
feel for exactly when it happens?  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

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.

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?
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.

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.

-- 

73,
Ged.