clamscan modifies atime during scheduled scans

Thanks for the report, Brandon.

I can confirm this behaviour, and here are simple reproducible steps to verify it:

# apt install clamav
# echo hi > test
# stat test
...
Access: 2021-02-10 19:53:04.982514441 +0000
...
# clamscan test
# stat test
Access: 2021-02-10 19:53:32.482243351 +0000

I'm not an expert in antivirus (it's been decades since I don't touch one), but I tend to agree to your conclusion here. Since this seems to be a minor severity problem, the best course of action would be to file an upstream bug here. Once you do so, please also update this bug report with a link to the upstream bug, so that we can monitor it. Then, when the next clamav version is released the fix will eventually land in Ubuntu as well.

Thank you very much, and please don't hesitate to comment here if there are any questions.

Upstream ticket for this: https://bugzilla.clamav.net/show_bug.cgi?id=12672
(however, please note that this may sit idle for a while as upstream has more priority issues to work on atm!)

Thank you! It looks like someone beat me to it, with a reference back to this bug:

https://bugzilla.clamav.net/show_bug.cgi?id=12672

Hi Brandon and Sergio,

Can you guys still reproduce this? I ran the steps Sergio outlined but didn't see the atime change:

triage-kinetic+22.10:~$ sudo apt install clamav
...
The following packages will be upgraded:
  clamav
1 upgraded, 0 newly installed, 0 to remove and 199 not upgraded.
Need to get 130 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu kinetic/main amd64 clamav amd64 0.103.6+dfsg-1ubuntu1 [130 kB]
Fetched 130 kB in 1s (167 kB/s)
(Reading database ... 71567 files and directories currently installed.)
Preparing to unpack .../clamav_0.103.6+dfsg-1ubuntu1_amd64.deb ...
Unpacking clamav (0.103.6+dfsg-1ubuntu1) over (0.103.6+dfsg-1ubuntu1) ...
Setting up clamav (0.103.6+dfsg-1ubuntu1) ...
Processing triggers for man-db (2.10.2-1) ...
triage-kinetic+22.10:~$ echo hi > test
triage-kinetic+22.10:~$ stat test
  File: test
  Size: 3 Blocks: 8 IO Block: 4096 regular file
Device: fd08h/64776d Inode: 274348 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ bryce) Gid: ( 1000/ bryce)
Access: 2022-06-07 15:49:13.832795785 +0000
Modify: 2022-06-07 15:49:13.832795785 +0000
Change: 2022-06-07 15:49:13.832795785 +0000
 Birth: 2022-06-07 15:49:13.832795785 +0000
triage-kinetic+22.10:~$ stat test | grep Access:
Access: (0664/-rw-rw-r--) Uid: ( 1000/ bryce) Gid: ( 1000/ bryce)
Access: 2022-06-07 15:49:13.832795785 +0000
triage-kinetic+22.10:~$ clamscan test
/home/bryce/test: OK

----------- SCAN SUMMARY -----------
Known viruses: 8617627
Engine version: 0.103.6
Scanned directories: 0
Scanned files: 1
Infected files: 0
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 19.603 sec (0 m 19 s)
Start Date: 2022:06:07 15:49:56
End Date: 2022:06:07 15:50:16
triage-kinetic+22.10:~$ stat test
  File: test
  Size: 3 Blocks: 8 IO Block: 4096 regular file
Device: fd08h/64776d Inode: 274348 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/ bryce) Gid: ( 1000/ bryce)
Access: 2022-06-07 15:49:13.832795785 +0000
Modify: 2022-06-07 15:49:13.832795785 +0000
Change: 2022-06-07 15:49:13.832795785 +0000
 Birth: 2022-06-07 15:49:13.832795785 +0000

I also tested on jammy and focal, which have already had the same clamav version backported, and similarly did not reproduce.

The upstream bug report is still open, and there are no mentions of atime fixes in the clamav changelog upstream, but I tested older versions of clamav - 0.103.5+dfsg-1 on jammy, and 0.102.2+dfsg-2ubuntu1 on focal, but also with those after running clamscan the Access, Birth and Modify times are identical and unchanged. Could this have been fixed elsewhere than clamav, or could there be some system settings necessary to reproduce?

Do you recall what clamav version you tested this on originally? Or what ubuntu release was used? Are you still able to reproduce the faulty behavior?

I am no longer able to reproduce this behavior, neither on Ubuntu 18.04 nor 20.04. I double-checked that I had both filesystems mounted with strictatime: the atime was updated when I ran `cat test`.

This is baffling because it was definitely a problem before, and I don't see references anywhere in the source code nor the patches to case-insensitive "atime". I'm not sure how, but it now appears to me to be fixed.

Hi Bryce, Brandon,

Indeed, the test I posted in comment #1 doesn't work anymore. I don't remember the version of clamav I used back then, unfortunately. I did some strace'ing and noticed something strange: clamav was opening the file, but wasn't actually reading anything. After investigating a bit, I found the following upstream commit:

https://github.com/Cisco-Talos/clamav/commit/e01ba94e36f1786a0bbd04631f12ed5f2afdd094

or, more specifically, this hunk:

https://github.com/Cisco-Talos/clamav/commit/e01ba94e36f1786a0bbd04631f12ed5f2afdd094#diff-9ea761d49c419551e2cc5b26230a94bcfcd4fd52f1d65ba237d7717bcef999b7

It checks to see if the file size is 5 bytes or less, and bails out if it is. Unfortunately my test file is too small and ends up triggering this.

In order to reproduce the bug, I'd suggest the following:

# dd if=/dev/zero of=test bs=1M count=1
# stat test
...
Access: 2022-06-08 20:17:56.454580579 +0000
# clamscan test
...
# stat test
...
Access: 2022-06-08 20:18:23.722421260 +0000

This has been tested on Focal using clamav 0.103.6+dfsg-0ubuntu0.20.04.1.

The upstream bug has not received any updates so far. The last paragraph of the report is a call for community contributions. Moreover, IMHO, it would be nice to get an upstream review for any potential patches to fix the issue in this specific case, since we will be changing how the software interacts with the system (i.e., this should be proposed to the upstream project first).

Still no updates in the upstream bug.