Automatically detecting files placed in my Downloads directory in Gentoo Linux and scanning them for viruses

I have been using Linux for almost a decade and have never been unduly concerned about viruses on my machines running Linux. However, I do receive files from people who use Windows and Mac OS, and some of those files might contain Windows or Mac OS viruses, so, as a matter of courtesy and assistance to others, it would make some sense to scan those files before passing them on. Furthermore, as I use some Windows applications under WINE, it would also make sense to scan received files for Windows viruses if I am going to use those files with a Windows application running under WINE.

External files could get into my Gentoo Linux installations via pen drives, memory cards, optical discs, e-mails, my Dropbox directory and downloads from Web sites. In this post I am going to concentrate on the last of these. All the various e-mail account providers I use already scan e-mails for viruses on their e-mail servers before I even download e-mail into the e-mail client on my laptop (standard practice these days), so e-mail is not a particular worry.

I have had ClamAV and its GUI, ClamTk, installed for a long time. Whilst ClamTk can be used to schedule a daily update of virus signatures and a daily scan of one’s home directory by ClamAV, I normally run ClamTk and ClamAV ad hoc. However, I can see some benefit in launching ClamAV automatically when I download a file from the Internet, so I decided to do the following …

Automatically scan a file downloaded via a Web browser

I use Firefox to browse the Web, and had configured it to download files to the directory /home/fitzcarraldo/Downloads/. I decided to monitor automatically the Downloads directory for the addition of any file. As I use the ext4 file system, the method I opted to use is inotify, specifically the inotifywait command which is available once you install the package sys-fs/inotify-tools.

It is surprisingly easy to create a shell script to detect files downloaded into a directory. The following script, running continuously in a terminal, would detect any files created in my /home/fitzcarraldo/Downloads directory, scan the new files with ClamAV and display a report in the terminal window:



inotifywait -q -m -e create --format '%w%f' $DIR | while read FILE
     echo "File $FILE has been detected. Scanning it for viruses now ..."
     clamscan $FILE

A usable script would need to be a bit more sophisticated than the one shown above, because an existing file in the directory could be overwritten by one with the same name, or opened and amended. Furthermore, the script above would need a permanently open terminal window. Therefore I created a script to run in the background and use a GUI dialogue tool to pop up a window with the virus scanner’s report when the script detects a new or changed file in the Downloads directory. As this laptop has KDE 4 installed I opted to use KDialog to display the pop-up window, but I could instead have used Zenity. The final script is shown below.



# Get rid of old log file
rm $HOME/virus-scan.log 2> /dev/null

inotifywait -q -m -e close_write,moved_to --format '%w%f' $DIR | while read FILE
     # Have to check file length is nonzero otherwise commands may be repeated
     if [ -s $FILE ]; then
          date > $HOME/virus-scan.log
          clamscan $FILE >> $HOME/virus-scan.log
          kdialog --title "Virus scan of $FILE" --msgbox "$(cat $HOME/virus-scan.log)"

Now when I download a file in Firefox, a window pops up, displaying a message similar to the following:

Virus scan of /home/fitzcarraldo/Downloads/ – KDialog

Fri 19 Feb 23:42:02 GMT 2016
/home/fitzcarraldo/Downloads/ Eicar-Test-Signature FOUND

———– SCAN SUMMARY ———–
Known viruses: 4259980
Engine version: 0.98.7
Scanned directories: 0
Scanned files: 1
Infected files: 1
Data scanned: 0.00 MB
Data read: 0.00 MB (ratio 0.00:1)
Time: 4.595 sec (0 m 4 s)

Notice in the above message that ClamAV detected a virus in a file that I downloaded from the European Expert Group for IT Security Web site (originally ‘European Institute for Computer Antivirus Research’). In fact the executable does not contain a real virus; it was designed to contain a known signature that virus scanner creators and users can use in checking anti-virus software. You can find out more about the virus test files on the EICAR Web site.

Of course, if I use applications other than Firefox to download files, I need to make sure they download the files into the applicable directory so that the script can detect and scan the files:

fitzcarraldo@clevow230ss ~ $ cd Downloads/
fitzcarraldo@clevow230ss ~/Downloads $ youtube-dl -o Carnavalito.mp4 -f 18
ZDUL3w7zFD4: Downloading webpage
ZDUL3w7zFD4: Downloading video info webpage
ZDUL3w7zFD4: Extracting video information
ZDUL3w7zFD4: Downloading MPD manifest
[download] Destination: Carnavalito.mp4
[download] 100% of 16.61MiB in 00:05

So, now I have a shell script that pops up a window informing me whether or not any file I put in $HOME/Downloads/ contains a virus. But I would like the script to be launched automatically when I login to the Desktop Environment. Therefore, as I use KDE 4, I selected ‘System Settings’ > ‘Startup and Shutdown’ and, in the ‘Autostart’ pane, clicked on ‘Add Script…’ and entered the path to my shell script (I left ‘create as symlink’ ticked). Now, every time I use KDE, any file placed (automatically or manually) into $HOME/Downloads/ is scanned for viruses automatically and a window pops up giving the result.

As my laptop is not always connected to the Internet, I prefer to update the ClamAV virus signatures database manually, which I do either using the ClamTk GUI or via the command line using the freshclam command:

fitzcarraldo@clevow230ss ~ $ su
clevow230ss fitzcarraldo # freshclam
ClamAV update process started at Sat Feb 20 10:51:01 2016
WARNING: Your ClamAV installation is OUTDATED!
WARNING: Local version: 0.98.7 Recommended version: 0.99
main.cvd is up to date (version: 55, sigs: 2424225, f-level: 60, builder: neo)
Downloading daily-21375.cdiff [100%]
Downloading daily-21376.cdiff [100%]
Downloading daily-21377.cdiff [100%]
Downloading daily-21378.cdiff [100%]
Downloading daily-21379.cdiff [100%]
Downloading daily-21380.cdiff [100%]
Downloading daily-21381.cdiff [100%]
Downloading daily-21382.cdiff [100%]
Downloading daily-21383.cdiff [100%]
Downloading daily-21384.cdiff [100%]
Downloading daily-21385.cdiff [100%]
Downloading daily-21386.cdiff [100%]
Downloading daily-21387.cdiff [100%]
Downloading daily-21388.cdiff [100%]
Downloading daily-21389.cdiff [100%]
Downloading daily-21390.cdiff [100%]
Downloading daily-21391.cdiff [100%]
daily.cld updated (version: 21391, sigs: 1850214, f-level: 63, builder: neo)
bytecode.cld is up to date (version: 271, sigs: 47, f-level: 63, builder: anvilleg)
Database updated (4274486 signatures) from (IP:
WARNING: Clamd was NOT notified: Can't connect to clamd through /var/run/clamav/clamd.sock: No such file or directory

Stopping my laptop spontaneously resuming immediately after Suspend to RAM

If I selected ‘Suspend to RAM’ via the Desktop Environment in the Gentoo Linux installation on my Clevo W230SS laptop, the laptop did suspend but then immediately resumed automatically. The same thing happened if I suspended the laptop using either of the following commands from the command line:

root # pm-suspend

user $ qdbus org.kde.Solid.PowerManagement /org/freedesktop/PowerManagement Suspend

This behaviour was annoying, as it meant I had to shut down the laptop completely when I was not at my desk for a long time, rather than just being able to suspend the laptop.

Problem 1: USB devices

I usually have several USB devices connected to my laptop when I am at home or in the office, and I began to suspect that these USB connections were somehow causing Linux to resume as soon as it had suspended. Searching the Web turned up a Q&A page that seemed to confirm my suspicion: Why does my laptop resume immediately after suspend? I installed the utility acpitool mentioned on that Web page and used it with the ‘-w‘ option to check which wakeup-capable USB devices were currently enabled in my installation:

root # acpitool -w
   Device       S-state   Status   Sysfs node
  1. RP01         S4    *disabled  pci:0000:00:1c.0
  2. PXSX         S4    *disabled
  3. RP02         S4    *disabled
  4. PXSX         S4    *disabled
  5. RP03         S4    *disabled  pci:0000:00:1c.2
  6. PXSX         S4    *disabled  pci:0000:03:00.0
  7. RP04         S4    *disabled  pci:0000:00:1c.3
  8. PXSX         S4    *disabled  pci:0000:04:00.0
  9.            *disabled  platform:rtsx_pci_sdmmc.0
  10.           *disabled  platform:rtsx_pci_ms.0
  11. RLAN        S4    *disabled
  12. RP05        S4    *disabled
  13. PXSX        S4    *disabled
  14. RP06        S4    *disabled
  15. PXSX        S4    *disabled
  16. RP07        S4    *disabled
  17. PXSX        S4    *disabled
  18. RP08        S4    *disabled
  19. PXSX        S4    *disabled
  20. GLAN        S4    *disabled
  21. EHC1        S3    *enabled   pci:0000:00:1d.0
  22. EHC2        S3    *enabled   pci:0000:00:1a.0
  23. XHC         S3    *disabled  pci:0000:00:14.0
  24. HDEF        S4    *disabled  pci:0000:00:1b.0
  25. PEG0        S4    *disabled  pci:0000:00:01.0
  26. PEGP        S4    *disabled  pci:0000:01:00.0
  27. PEGA        S4    *disabled
  28. PWRB        S3    *enabled   platform:PNP0C0C:0
root #

(I had to use Ctrl-C to get back to the command prompt.)

I then used the command ‘acpitool -W <device number>‘ on each of the three enabled devices (21, 22 and 28 above) in order to find out which of them needed to be disabled in order for my laptop to remain suspended when I suspended it. I found that I only needed to disable devices EHC1 (pci:0000:00:1d.0) and EHC2 (pci:0000:00:1a.0) to be able to suspend the laptop successfully:

root # acpitool -W 21 | grep 21
  Changed status for wakeup device #21 (EHC1)
  21. EHC1        S3    *disabled  pci:0000:00:1d.0
root # acpitool -W 22 | grep 22
  Changed status for wakeup device #22 (EHC2)
  22. EHC2        S3    *disabled  pci:0000:00:1a.0
root # pm-suspend

In this laptop these two devices are two internal USB root hubs:

user $ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
        |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 480M
            |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
        |__ Port 2: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 1: Dev 6, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 4: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 4: Dev 7, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 4, If 0, Class=Wireless, Driver=btusb, 12M
        |__ Port 3: Dev 4, If 1, Class=Wireless, Driver=btusb, 12M
        |__ Port 4: Dev 5, If 0, Class=Video, Driver=uvcvideo, 480M
        |__ Port 4: Dev 5, If 1, Class=Video, Driver=uvcvideo, 480M

The next challenge was to find out how to disable and re-enable the two devices automatically when I suspend and resume the installation. Further searching of the Web turned up another Q&A page which pointed me in the right direction: How to run a script when suspending/resuming?. It turns out that you need to put a script of the following form in the directory /etc/pm/sleep.d/:


case "$1" in
        # executed on suspend
        # executed on resume

If you want the script to run when hibernating and thawing, the tests would be for ‘hibernate‘ and ‘thaw‘ instead of ‘suspend‘ and ‘resume‘.

The thread [SOLVED] Computer immediately resumes after suspend in the KDE Forums almost gave me the solution I needed. I created a file /etc/pm/sleep.d/01-toggle-usb-hubs containing the following:

export XAUTHORITY="$userhome/.Xauthority"
export DISPLAY=":0"
case "$1" in
        # Unbind ehci-pci for the device 0000:00:1a.0
        echo -n "0000:00:1a.0" | tee /sys/bus/pci/drivers/ehci-pci/unbind
        # Unbind ehci-pci for the device 0000:00:1d.0
        echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/unbind
        # Bind ehci-pci for the device 0000:00:1a.0
        echo -n "0000:00:1a.0" | tee /sys/bus/pci/drivers/ehci-pci/bind
        # Bind ehci-pci for the device 0000:00:1d.0
        echo -n "0000:00:1d.0" | tee /sys/bus/pci/drivers/ehci-pci/bind
        exit $NA

I obtained the device details from the output of the ‘acpitools -w‘ command listed earlier and by looking in the directory /sys/bus/pci/drivers/ehci-pci:

root # ls /sys/bus/pci/drivers/ehci-pci
0000:00:1a.0  0000:00:1d.0  bind  new_id  remove_id  uevent  unbind

Notice that the script tests for either ‘suspend‘ or ‘hibernate‘ to disable the two devices, and tests for either ‘resume‘ or ‘thaw‘ to enable the two devices.

I made the script executable:

root # chmod +x /etc/pm/sleep.d/01-toggle-usb-hubs

Problem 2: Blank X Windows display due to NVIDIA closed-source driver bug

However, a problem remained: My laptop has an NVIDIA GPU and, when resuming from suspension, the X Windows display (Virtual Terminal 7) was a blank screen with only the mouse pointer visible. Now, it so happens that I also experience this behaviour if I switch from Virtual Terminal 7 to e.g. Virtual Terminal 1 (Ctrl-Alt-F1) and then switch back to Virtual Terminal 7 (Ctrl-Alt-F7). Apparently this is due to a bug in the closed-source NVIDIA driver (I am currently using Gentoo package x11-drivers/nvidia-drivers-358.16-r1). However, if I first disable compositing before switching to another virtual terminal, the X Windows display on Virtual Terminal 7 is still visible when I switch back to Virtual Terminal 7. It turns out there is a known bug in the NVIDIA closed-source driver, as explained in the following KDE bug report and thread in the NVIDIA CUDA ZONE Forums:

KDE Bugtracking System Bug No. 344326 – Black or corrupted screen on resume from suspend

NVIDIA CUDA ZONE Forums – Black screen on resume from suspend with 325.15 and KWin 4.11 with enabled compositing

As the suggested work-around is to disable compositing before suspending to RAM, I created a script /etc/pm/sleep.d/02-toggle-compositing containing the following:

export XAUTHORITY="$userhome/.Xauthority"
export DISPLAY=":0"
case "$1" in
        su $username -c "qdbus org.kde.kwin /KWin toggleCompositing" &
        su $username -c "qdbus org.kde.kwin /KWin toggleCompositing" &
        exit $NA

As I have KDE 4 on this laptop, I made the script use the command ‘qdbus org.kde.kwin /KWin toggleCompositing‘ to disable/enable compositing, so replace that command with the appropriate command if you are not using KDE 4.

I made the script executable:

root # chmod +x /etc/pm/sleep.d/02-toggle-compositing

Now both the scripts in the directory /etc/pm/sleep.d/ run when I suspend or resume the laptop, and everything works as expected. Mission accomplished! 🙂