FAQ: ClamAV Issue when Running Sentry on CentOS 7

There is a potential ClamAV virus scanning issue with the Sentry software instance running on CentOS 7.  The following error may be seen in the logs:

 

ClamAV_on_7.png

 

This is due to ClamAV not being able to read the files Sentry is writing to in /tmp.  More specifically, it is an issue where PrivateTmp is set to TRUE in the ClamAV system service as seen below:

 

# cat /usr/lib/systemd/system/clamd@.service

[Unit]

Description = clamd scanner (%i) daemon

After = syslog.target nss-lookup.target network.target

[Service]

Type = simple

ExecStart = /usr/sbin/clamd -c /etc/clamd.d/%i.conf --nofork=yes

Restart = on-failure

PrivateTmp = true

 

More information on PrivateTmp is included below.

 

To resolve this issue, set PrivateTmp to false then restart ClamAV.

The following should now be shown in the log upon successful scan:

ClamAV_2_on_7.png

 

More information on PrivateTmp can be found at: https://fedoraproject.org/wiki/Features/ServicesPrivateTmp

http://www.freedesktop.org/software/systemd/man/systemd.exec.html


PrivateTmp=
Takes a boolean argument. If true, sets up a new file system namespace for the executed processes and mounts private /tmp and /var/tmp directories inside it that is not shared by processes outside of the namespace. This is useful to secure access to temporary files of the process, but makes sharing between processes via /tmp or /var/tmp impossible. If this is enabled, all temporary files created by a service in these directories will be removed after the service is stopped. Defaults to false. It is possible to run two or more units within the same private /tmp and /var/tmp namespace by using the JoinsNamespaceOf= directive, see systemd.unit(5) for details. Note that using this setting will disconnect propagation of mounts from the service to the host (propagation in the opposite direction continues to work). This means that this setting may not be used for services which shall be able to install mount points in the main mount namespace.

0 Comments

Article is closed for comments.