Hello, I have had the same experience and chosen the following solution.
I am supposing from your description that you have applied the "Use Case 0x0" configuration recipe from
https://www.clamav.net/documents/on-access-scanning with OnAccessMountPath / and some user exclusions (including perhaps excluding root). Also you confirmed that OnAcessPrevention was off. Therefore, as far as I can make out, the reason for the message that is appearing in the logs is given in the comment documentation for OnAccessExcludeUID in /etc/clamd.d/scan.conf:
Code: Select all
# Also note that if clamd cannot check the uid of the process that generated an
# on-access scan event (e.g., because OnAccessPrevention was not enabled, and
# the process already exited), clamd will perform a scan. Thus, setting
# OnAccessExcludeUID is not *guaranteed* to prevent every access by the
# specified uid from triggering a scan (unless OnAccessPrevention is enabled).
You said "I've tried adding /proc/ to excluded directories"; if you tried to do this with OnAccessExcludePath, that won't work with OnAccessMountPath. From what I understand of the documentation, OnAccessMountPath uses a certain kernel fanotify configuration giving it efficient notifications of all access events in entire filesystems. Whereas OnAccessExcludePath works with OnAccessIncludePath, which uses ClamAV's "DDD" system based on a different fanotify configuration. In my case I found that OnAccess{Include,Exclude}Path / DDD was prohibitively expensive CPU-wise.
Personally I tried multiple OnAccessMountPath directives limited to various folders (mainly root ones) without mentioning / or /proc . This did not work: I suppose it confirms that OnAccessMountPath works for entire filesystems and that trying to target subfolders only, even root ones, just includes the entire filesystem they are part of (so in my case, I suppose that OnAccessMountPath /usr sort of implied OnAccessMountPath /, since /usr was
not a separate filesystem, and that in turn meant that /proc was being monitored again).
At the end of the day I decided to simply silence clamonacc's
standard output. That is where the message is coming from. Unfortunately, simply adding --log=/dev/null to the commandline in clamonacc.service's Unit File did not work. I had to do it at the systemd level, with the StandardOutput=null directive in the [Service] section. I am automating such configuration so I did it as properly as I could, leveraging systemd's Unit File snippet system with the "edit" command (it creates a /etc/systemd/system/clamonacc.service.d/override.conf file and automatically does daemon-reload so the file will be merged, prioritarily, with the standard /usr/lib/systemd/system/clamonacc.service); and because systemctl edit would normally use an interactive editor such as vi for the job, precluding a standard input heredoc, I overrode SYSTEMD_EDITOR (kudos to
https://bbs.archlinux.org/viewtopic.php?id=195782):
----- TL;DR start here -----
Code: Select all
sudo SYSTEMD_EDITOR=tee systemctl edit clamonacc.service << 'EOF'
[Service]
StandardOutput=null
EOF
I'm hoping that silencing only the standard output from clamonacc, which is run as --foreground in the Unit File service definition provided for CentOS, will not prevent true error conditions from appearing in the system logs from its standard error output. Also infection detections are logged separately by the clamd@scan service anyway.