Bug 12306 - ScanOnAccess: Could not watch path '/var', Success
ScanOnAccess: Could not watch path '/var', Success
Status: ASSIGNED
Product: ClamAV
Classification: ClamAV
Component: clamd
stable
x86_64 GNU/Linux
: P3 normal
: 0.101.0
Assigned To: ClamAV team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-03-22 04:06 EDT by Franky Van Liedekerke
Modified: 2019-09-27 13:37 EDT (History)
2 users (show)

See Also:
QA Contact:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Franky Van Liedekerke 2019-03-22 04:06:26 EDT
Using clamd-0.101.1-1.el7.x86_64 on a RHEL7.6, I get this:

Mar 22 08:39:16 systemd: Started Generic clamav scanner daemon.
Mar 22 08:39:17 clamd[5736]: ScanOnAccess: Protecting directory '/usr' (and all sub-directories)
Mar 22 08:39:17 clamd[5736]: ScanOnAccess: Protecting directory '/etc' (and all sub-directories)
Mar 22 08:39:18 clamd[5736]: ScanOnAccess: Protecting directory '/var' (and all sub-directories)
Mar 22 08:39:18 clamd[5736]: ScanOnAccess: Protecting directory '/opt' (and all sub-directories)
Mar 22 08:39:18 clamd[5736]: ScanOnAccess: Could not watch path '/var', Success

Relevant part of the config is:
OnAccessIncludePath /home
OnAccessIncludePath /usr
OnAccessIncludePath /etc
OnAccessIncludePath /var
OnAccessIncludePath /opt

It seems https://forums.opensuse.org/showthread.php/524811-clamd-ScanOnAccess-no-longer-working is identical and there it mentions a bug (11602) in clamd which was fixed in dev on 18-May-2017. I can't find that bug but the suse-thread talks about clamd and bailing out on sockets. After some digging around, I found this commit: https://github.com/Cisco-Talos/clamav-devel/commit/4edbeea04c9f9fd7efb4a22914becdac1d4df1b9
but the comment in that commit says it all: it doesn't work.
I do have sockets in /var of course, so is there a newer fix for this? Or a config setting I can try (to exclude sockets all together)? Sockets can get created on a number of locations, but I can't just ignore /var completely (well, yes, of course I could do it in the config, but that is besides the point :-) ).

Franky
Comment 1 Mickey Sola 2019-03-22 13:49:49 EDT
This commit fixed the socket issue (https://github.com/Cisco-Talos/clamav-devel/commit/0bde9405f6f25c2b41017569a2b3cd586c63d719), but I don't think that's what you're seeing here.

Given the nature of /var I believe a race condition involving watchpoints on particular system files/directories is more likely. To figure out the cause, I ask that you write your clamd.config with an IncludePath option for each subdirectory of /var so that we might be able to better narrow down the exact culprit.

Assuming the socket fix above (which should already be in your copy of clam unless your distributors removed it) doesn't pan out for you.
Comment 2 Franky Van Liedekerke 2019-03-25 08:40:47 EDT
I'm using the rpm built by EPEL for EL7: https://dl.fedoraproject.org/pub/epel/7/SRPMS/Packages/c/clamav-0.101.1-1.el7.src.rpm
Currently our proxy@work is blocking access to this file, but let's assume that fix is in it.
It seems that in /var 2 directories are causing a problem:

/var/lib/nfs/rpc_pipefs (mounted as sunprc with type rpc_pipefs)
/var/log/journal (separate mountpoint for journal logs)


Next, /opt was also not working. There it seems that /opt/openv is the problem dir, but doing only "OnAccessIncludePath /opt/openv" works fine. Setting /opt *and* "OnAccessExcludePath /opt/openv" works too.
The only "weird" thing is that /opt/openv is a separate mountpoint in /opt.

In fact, it seems that any directory mounted as a subdir of an OnAccessIncludePath-setting, causes it to fail (this matches /opt/openv, /var/log/journal and /var/lib/nfs/rpc_pipefs too). Is this a known issue?
Comment 3 Mickey Sola 2019-03-25 13:08:56 EDT
This is a new find, afaik. Thanks for looking into it. This issue may be a limitation with the function used to traverse/map out the initial file system hierarchy. I'll investigate further and look to include a fix alongside the other major upcoming OnAccess updates.
Comment 4 Franky Van Liedekerke 2019-04-08 10:44:32 EDT
Do you by any chance have any news on this? It would be nice to be able to work fine-grained (and the Mount-onaccess option does not allow that).
Comment 5 Mickey Sola 2019-04-08 13:27:16 EDT
It's on the "to fix/look at" list alongside a bunch of other on-access stuff which I'm actively working on at the moment. These changes will all likely go out at once and will hit our github repo before a proper release occurs. I'll update this ticket when I find out more.
Comment 6 Franky Van Liedekerke 2019-04-15 07:36:37 EDT
Some extra info: a workaround seems to be to mention the submounts first. So this works to monitor /opt (assuming /opt/openv is a submount):

OnAccessIncludePath /opt/openv
OnAccessIncludePath /opt

but this doesn't:
OnAccessIncludePath /opt
OnAccessIncludePath /opt/openv

So it really seems to be a small issue in how the watches are set up :-)
But with this workaround I can test things a little more.

Franky
Comment 7 Franky Van Liedekerke 2019-08-20 05:27:52 EDT
Hi,
4 months further down the road I'm curious if the new 0.102.0 (with the separate clamonacc) would fix this? Of course I know that release is still in beta for now.
Comment 8 Mickey Sola 2019-08-20 12:42:03 EDT
Hi Franky,

Some watch setup tweaks made it into the new version, including a way to pass a list of include and exclude paths on the command line at run time, but with everything that went into the 0.102 OnAccess changes, lots of fixes and improvements I wanted to do I didn't have the cycles to make happen. This fix was one of those, unfortunately.
Comment 9 Micah Snyder 2019-09-27 13:37:44 EDT
Removing the "security" tag.