clamd.log:

Sun Jul  1 18:04:01 2018 -> +++ Started at Sun Jul  1 18:04:01 2018
Sun Jul  1 18:04:01 2018 -> Received 1 file descriptor(s) from systemd.
Sun Jul  1 18:04:01 2018 -> clamd daemon 0.100.0 (OS: linux-gnu, ARCH: x86_64, CPU: x86_64)
Sun Jul  1 18:04:01 2018 -> Running as user root (UID 0, GID 0)
Sun Jul  1 18:04:01 2018 -> Log file size limited to 1048576 bytes.
Sun Jul  1 18:04:01 2018 -> Reading databases from /var/lib/clamav
Sun Jul  1 18:04:01 2018 -> Not loading PUA signatures.
Sun Jul  1 18:04:01 2018 -> Bytecode: Security mode set to "TrustSigned".
Sun Jul  1 18:04:14 2018 -> Loaded 9755629 signatures.
Sun Jul  1 18:04:14 2018 -> TCP: No tcp AF_INET/AF_INET6 SOCK_STREAM socket received from systemd.
Sun Jul  1 18:04:14 2018 -> LOCAL: Received AF_UNIX SOCK_STREAM socket from systemd.
Sun Jul  1 18:04:14 2018 -> Limits: Global size limit set to 104857600 bytes.
Sun Jul  1 18:04:14 2018 -> Limits: File size limit set to 26214400 bytes.
Sun Jul  1 18:04:14 2018 -> Limits: Recursion level limit set to 16.
Sun Jul  1 18:04:14 2018 -> Limits: Files limit set to 10000.
Sun Jul  1 18:04:14 2018 -> Limits: MaxEmbeddedPE limit set to 10485760 bytes.
Sun Jul  1 18:04:14 2018 -> Limits: MaxHTMLNormalize limit set to 10485760 bytes.
Sun Jul  1 18:04:14 2018 -> Limits: MaxHTMLNoTags limit set to 2097152 bytes.
Sun Jul  1 18:04:14 2018 -> Limits: MaxScriptNormalize limit set to 5242880 bytes.
Sun Jul  1 18:04:14 2018 -> Limits: MaxZipTypeRcg limit set to 1048576 bytes.
Sun Jul  1 18:04:14 2018 -> Limits: MaxPartitions limit set to 50.
Sun Jul  1 18:04:14 2018 -> Limits: MaxIconsPE limit set to 100.
Sun Jul  1 18:04:14 2018 -> Limits: MaxRecHWP3 limit set to 16.
Sun Jul  1 18:04:14 2018 -> Limits: PCREMatchLimit limit set to 100000.
Sun Jul  1 18:04:14 2018 -> Limits: PCRERecMatchLimit limit set to 5000.
Sun Jul  1 18:04:14 2018 -> Limits: PCREMaxFileSize limit set to 26214400.
Sun Jul  1 18:04:14 2018 -> Archive support enabled.
Sun Jul  1 18:04:14 2018 -> BlockMax heuristic detection disabled.
Sun Jul  1 18:04:14 2018 -> Algorithmic detection enabled.
Sun Jul  1 18:04:14 2018 -> Portable Executable support enabled.
Sun Jul  1 18:04:14 2018 -> ELF support enabled.
Sun Jul  1 18:04:14 2018 -> Mail files support enabled.
Sun Jul  1 18:04:14 2018 -> OLE2 support enabled.
Sun Jul  1 18:04:14 2018 -> PDF support enabled.
Sun Jul  1 18:04:14 2018 -> SWF support enabled.
Sun Jul  1 18:04:14 2018 -> HTML support enabled.
Sun Jul  1 18:04:14 2018 -> XMLDOCS support enabled.
Sun Jul  1 18:04:14 2018 -> HWP3 support enabled.
Sun Jul  1 18:04:14 2018 -> Self checking every 600 seconds.
Sun Jul  1 18:04:14 2018 -> ScanOnAccess: notifying only for access attempts.
Sun Jul  1 18:04:14 2018 -> ScanOnAccess: Max file size limited to 104857600 bytes
Sun Jul  1 18:04:14 2018 -> ScanOnAccess: Protecting directory '/home/taiki/Downloads' (and all sub-directories)
Sun Jul  1 18:04:14 2018 -> ScanOnAccess: Extra scanning and notifications enabled.
Sun Jul  1 18:04:20 2018 -> ScanOnAccess: /home/taiki/Downloads/eicar.com.txt: Eicar-Test-Signature FOUND
Sun Jul  1 18:04:21 2018 -> ScanOnAccess: /home/taiki/Downloads/eicar.com.txt: Eicar-Test-Signature FOUND
Sun Jul  1 18:04:21 2018 -> ScanOnAccess: /home/taiki/Downloads/eicar.com.txt: Eicar-Test-Signature FOUND

This is currently done on purpose because the virusevent function forks the calling process. That has the potential to get extremely messy extremely quickly since onaccess runs in a separate thread from the main clamd process.

I imagine if it were enabled you'd see massive memory leaks, resource contention issues, and other unforeseen problems on your system(s).

We'll look into enabling it in the future if we can find an elegant way to minimize some of the drawbacks.

Thanks for your reply.
I hope that it will be fixed in the future.

*** Bug 12171 has been marked as a duplicate of this bug. ***

Hi

I am facing the same issue - but then, how can I instruct clamd to destroy the file when it discovers it using the onaccess handler?

(In reply to bibikitrinke from comment #5)
> Hi
> 
> I am facing the same issue - but then, how can I instruct clamd to destroy
> the file when it discovers it using the onaccess handler?

I highly recommend against automatically deleting files that any AV alerts on.  False positives are not uncommon, and in particularly bad occurrences it may remove critical components of installed software or system files.  

With VirusEvent disabled for onaccess, your best options may be to either use the OnAccessPrevention option to block access to the file, and log the event, or to monitor the log with a script and move the file to a "quarantine" directory so you can investigate the file before you delete it.  

I welcome suggestions from others on the topic.

yeah that's what I ended up doing (real time parsing of the log)

For those interested:

#!/bin/sh
tail -fn0 /var/log/clamav/clamav.log | \
while read line ; do
        echo "$line" | grep -oP "ScanOnAccess: \K(.*)(?=:(.*) FOUND)"
        if [ $? = 0 ]
        then
			virusfile=$(echo "$line" | grep -oP "ScanOnAccess: \K(.*)(?=:(.*) FOUND)" | grep -oP "(.*)(?=:(.*))")
			if [ -n "$virusfile" ]
			then
				echo "Found and quarantined virus file: $virusfile" >> /var/log/clamav/clamav-cleaner.log
				mv $virusfile /path/to/quarantine/
			fi
        fi
done

I also have just run into this.
I use to have this working  fine and I had no issues.
I will have to implement the suggest work around and have a cron job monitor the log file but are there any plan's to re-implement this?
Our security policy dictates that we have real-time AV scanning on all systems so running a scheduled scan of the logfile to alert isn't really inline with this, it's not technically real-time.

We're presently investigating migrating the on-access scanning feature out of clamd into a separate tool that interacts with clamd, the same way that clamav-milter and clamdscan work.  Ensuring that VirusEvent works when using the new On-Access scanning tool will be a part of that task.

The primary reason we're taking this approach is to eliminate the need to run clamd with root privileges.

Work is still in the experimental/research phase and the completed feature is targeted for the 0.102 version.

The workaround presented in comment 7 *is* a realtime solution, which should fit your needs nicely.

I will note that once set up, Prevention gets you blocking at the kernel level tied into detection, which is about as good as it gets when it comes to stopping malicious files from doing their thing. 

Prevention doesn't stop you from moving the file to quarantine via a cronjob at a later time. And it's far and away the fastest acting solution of the three--working as close to realtime as it's possible to get.

It looks like we neglected to close this ticket after 0.102 was released with the separate clamonacc on-access scanning clamd client. VirusEvent when using clamonacc should work.  

I would note that the VirusEvent is run by clamd, not by clamonacc, so whatever your event command is needs to be able to be run by clamd for it to work.

To be honest, I'm not sure why the VirusEvent isn't run by clamdscan, clamonacc, or clamav-milter instead, but that's how the original design was. 

Anyways, I'm closing this ticket as it is now possible to use VirusEvent with on-access scanning.