Hi there,
On Tue, 13 Jul 2021, Robert Kudyba wrote:
... daily.cld was updated, presumably by freshclam. That's good, as
nothing seems to have broken. Can you confirm that happened from the
freshclam log?
here are the logs from 10:01 AM Jul 13:
Jul 13 10:01:02 storm freshclam[3930506]: Database test passed.
Jul 13 10:01:02 storm freshclam[3930506]: daily.cld updated (version: 26230,
sigs: 3995778, f-level: 63, builder: raynman)
Jul 13 10:01:02 storm freshclam[3930506]: daily.cld updated (version: 26230,
sigs: 3995778, f-level: 63, builder: raynman)
...
ps -auwx|grep freshclam
clamav 3818 0.0 0.0 28952 12864 ? Ss 12:00 0:00
/usr/bin/freshclam -d --foreground=true
The logs contain a lot of duplicated lines. Maybe you have both a
line like
StandardOutput=syslog
in your freshclam.service and *also* a line like
LogSyslog yes
in your freshclam.conf (or whatever passes for freshclam.conf in these
screwy RedHat systems). Well, you want one or the other but not both.
I'd suggest commenting out the "LogSyslog yes" line and restarting the
freshclam daemon.
Are you sure that the system time gets set correctly at boot? We
need to know that we can rely on the timestamps in the logs. ...
...
Jul 13 12:00:50 ourserver.edu systemd[1]: Starting NTP client/server...
Jul 13 12:01:34 ourserver.edu chronyd[3232]: Selected source 50.205.57.38
(2.fedora.pool.ntp.org)
Looks good.
Anyway, suddenly the owner/group IDs have changed and you have both a
daily.cld and a daily.cvd - which isn't good news, especially as one
of them is over three weeks old. Where did it come from?
Right, that's the question.
Looks like it was either the update or the reboot. An easy way to
find out would be to just reboot.
Assuming that we can believe the timestamps, then any problems that
arose from ownership by the clamupdate user/group had already happened
at 12:02 so it was *not* the run of clamav-unofficial-sigs.sh at 12:14
which caused them.
Is this the first time that clamav-unofficial-sigs.sh ran?
No it's been running all the time.
I think we're confusing each other. The clamav-unofficial-sigs.sh
script doesn't run like a daemon runs. The script is started by
something like a cron entry; it updates the configured databases if
needed, then stops. The unofficial update script only updates (or
should only update) the third-party signature database files, that is
everything except 'main', 'daily' and 'bytecode'. I meant was it at
12:14 that the clamav-unofficial-sigs.sh script ran? Presumably it's
logging its activities somewhere, do you have that log? The log
location will be set in the configuration for the unofficial script.
So are freshclam and clamav-unofficial-sigs.sh not supposed to run
as separate processes?
They are completely separate, they know nothing about each other and it
would be bad if they both tried to update the same files. The ClamaV
team provide freshclam as part of the ClamAV 'official' distribution.
The clamav-unofficial-sigs.sh is optional, and is provided separately.
There are completely separate configuration files for both utilities.
I'm beginning to wonder if this is all down to installation of the
unofficial update script with a configuration which assumes that the
user:group should be the same user:group as the clamd daemon and not
the same user:group as the freshclam daemon. The clamd daemon only
needs to read the dababase files but freshclam needs to write them.
I can sort of imagine somebody at RedHat thinking they'd make the
update process and the scanning processes use different UIDs & GIDs
for extra security, but it's not a lot of extra security, and it's
just asking for this kind of trouble when somebody installs another
utility which updates files in the same directory.
What's in the freshclam log about these times?
Nothing as the upgrade/reboot was still happening. The next freshclam is:
Jul 13 14:00:58 ourserver freshclam[3818]: Received signal: wake up
Jul 13 14:00:58 ourserver freshclam[3818]: ClamAV update process started at Tue
Jul 13 14:00:58 2021
Jul 13 14:00:58 ourserver freshclam[3818]: Received signal: wake up
Jul 13 14:00:58 ourserver freshclam[3818]: ClamAV update process started at Tue
Jul 13 14:00:58 2021
Jul 13 14:00:58 ourserver freshclam[3818]: ERROR: Can't create temporary
directory /var/lib/clamav/tmp.21024dac47
Jul 13 14:00:58 ourserver freshclam[3818]: Hint: The database directory must be
writable for UID 985 or GID 981
Jul 13 14:00:58 ourserver freshclam[3818]: ERROR: Update failed.
Jul 13 14:00:58 ourserver freshclam[3818]: Can't create temporary directory
/var/lib/clamav/tmp.21024dac47
Jul 13 14:00:58 ourserver freshclam[3818]: Hint: The database directory must be
writable for UID 985 or GID 981
Jul 13 14:00:58 ourserver freshclam[3818]: Update failed.
Jul 13 14:00:58 ourserver freshclam[3818]:
The "Hint:" part tells you what the problem is. Something changed the
permissions on the directory /var/lib/clamav/, freshclam can no longer
create the temporary directory it needs for the update. I guess the
unofficial update script disagrees with freshclam about the user and
group for the database directory. I believe freshclam is running as
user clamupdate, group clamupdate (983:979) but you have the ownership
on the directory set to user clamav, group clamav (985:981). Note
that the only things which need to be able to write to the directory
are freshclam and the unofficial update script. These two must be
configured to use the same user:group (or at least so that they can
both write into the directory). Find out where these things are
configured and set them the same. If RedHat updates are setting the
configuration of the freshclam daemon to use clamupdate:clamupdate it
would explain why this happens after an update. In that case it may
be better to settle on clamupdate:clamupdate for both freshclam and
the unofficial script. It's also possible that you have something in
the startup which is setting the directory user:group too, we'll take
a look at that later if need be.
After all this you may have to manually set the user/group IDs of
/var/lib/clamav/ and the files in there (you can do that with the
'chown' and 'chgrp' commands) and you'll need to restart the freshclam
daemon (again).
Finally when the dust has settled and you're happy that it isn't going
to break again you can stop the cron job logging the permissions. But
leave it running until you're sure. :)
HTH
--
73,
Ged.
_______________________________________________
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
