Whenever freshclam gets restarted, either manually or automatically
during package upgrades, I get an apparmor denial in the logs. I
haven't seen any adverse effects from this denial. Reading the
capabilities(7) manual page where CAP_DAC_READ_SEARCH is mentioned,
there doesn't seem to be any reason for freshclam to need this
capability so I don't think the freshclam binary should be using this
capability. I note that the clamav codebase doesn't mention this
capability at all. I note that the apparmor profile mentions
dac_override and a comment next to that mentions a Launchpad bug that
explains this is for the AllowSupplementaryGroups option, which is
disabled by default. I wonder if whatever allows that to work has
switched from dac_override to dac_read_search, but I'm still not sure
why freshclam should also be using that capability.

https://manpages.debian.org/capabilities
https://launchpad.net/bugs/433764

   May 23 08:16:39 sudo[95446]:     pabs : TTY=pts/7 ; PWD=/home/pabs ; USER=root ; COMMAND=/usr/sbin/service clamav-freshclam restart
   May 23 08:16:39 sudo[95446]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1000)
   May 23 08:16:39 kernel: audit: type=1400 audit(1621728999.029:77): apparmor="DENIED" operation="capable" profile="/usr/bin/freshclam" pid=95452 comm="freshclam" capability=2  capname="dac_read_search"
   May 23 08:16:39 audit[95452]: AVC apparmor="DENIED" operation="capable" profile="/usr/bin/freshclam" pid=95452 comm="freshclam" capability=2  capname="dac_read_search"
   May 23 08:16:39 freshclam[95358]: Update process terminated
   May 23 08:16:39 sudo[95446]: pam_unix(sudo:session): session closed for user root
   May 23 08:16:39 systemd[1]: Stopping ClamAV virus database updater...
   May 23 08:16:39 systemd[1]: clamav-freshclam.service: Succeeded.
   May 23 08:16:39 freshclam[95452]: ClamAV update process started at Sun May 23 08:16:39 2021
   May 23 08:16:39 freshclam[95452]: daily.cld database is up-to-date (version: 26178, sigs: 3982081, f-level: 63, builder: raynman)
   May 23 08:16:39 freshclam[95452]: main.cld database is up-to-date (version: 59, sigs: 4564902, f-level: 60, builder: sigmgr)
   May 23 08:16:39 freshclam[95452]: bytecode.cld database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)
   May 23 08:16:39 systemd[1]: Stopped ClamAV virus database updater.
   May 23 08:16:39 systemd[1]: Started ClamAV virus database updater.
--- data dir ---
total 635564
-rw-r--r-- 1 clamav                 clamav                   1438720 Mar  8 23:55 bytecode.cld
drwxr-xr-x 2 clamav                 clamav                      4096 Sep  4  2017 clamav-b20b7008eebb4b9e94a5ddaf4a41c8e7.tmp
-rw-r--r-- 1 clamav                 clamav                 324139520 May 22 19:45 daily.cld
-rw-r--r-- 1 clamav                 clamav                 307403264 Nov 26  2019 main.cld
-rw------- 1 clamav                 clamav                        69 Apr 13 12:24 mirrors.dat
drwxr-xr-x 2 clamav                 clamav                      4096 Sep 24  2020 tmp.a8a4c

should be same thing I have here for testing. And I don't see it. But
you have while freshclam is killed not on start up.

There is this in my journal:
|Oct 31 23:30:41 debsidamd64 audit[450]: AVC apparmor="DENIED" operation="capable" profile="/usr/bin/freshclam" pid=450 comm="freshclam" capability=1  capname="dac_override"

which is from the time before dac_override got added. The Debian bug was
#972974.
I know that AllowSupplementaryGroups is marked as deprecated but this is
the default now. That means initgroups() (the code that was hidden
behind AllowSupplementaryGroups) is always executed.

Sebastian

I just tried it now. The first time I restarted freshclam it happened,
but the second time and third times it did not happen but then the
fourth time it did happen. Then I did a shell loop restarting 4 times
with 0.5s sleep in between and it happened 3 out of 4 times. Then I did
it 4 times again with 1s sleep in between and it happened 0 times. Then
I did it with 4 times again with 0.1s sleep and it happened only once.
Repeating the 0.5s restarts a bit later I got it 0 times.

So I'm guessing it is caused by some kind of race condition.

Correct.