[clamav-users] Can't access file ERROR - clamdscan - 0.103.7-1

Wed Nov 9 15:38:23 UTC 2022

Dear Ged,

thanks for the exhaustive analysis. I guess I identified the issue,
which is  *not* related to clamav itself.

Instead, the temporary directory that is specified in clamd
configuration file became very large for some reason. This resulted in
any command executed against this directory (rm, ls, etc.) to take
several minutes. While clamdscan was operating it interacted with this
directory but these interactions got timed out I believe resulting in
the observed Can't access file ERROR.

I was able to get to the bottom of this by appending "--stream" to
clamdscan to receive some debugging information. Using the additional
information I was able to pin-point the issue.

Best,
André

Am Mo., 7. Nov. 2022 um 18:02 Uhr schrieb G.W. Haywood via
clamav-users <clamav-users at lists.clamav.net>:
>
> Hello again,
>
> On Mon, 7 Nov 2022, An Schall via clamav-users wrote:
>
> > the command we are using is:
> >
> > sudo -H clamdscan -v -c /etc/clamd.d/scan.conf --multiscan --fdpass
>
> Try it without '--fdpass'.  What do you mean the '-H' to do for you?
>
> [Micah, I've just noticed that '-c file' doesn't appear in the 'man'
> page for clamd.conf but '--config-file=file' does.  I *think* I've
> mentioned it before but I don't have time to check right now.  The
> short version does work instead of the long one, I guess you know.]
>
> > We do see the errors in /var/log/clamdscan.log as defined in the
> > configuration file /etc/clamd.d/scan.conf (see below). The exact error
> > messages are as follows:
> >
> > Mon Nov  7 13:50:21 2022 -> /data/av-buffer/tmpFilesArchives/clamav-0.103.6-1.fc36/usr/bin/clamconf: Can't access file ERROR
> > Mon Nov  7 13:50:21 2022 -> /data/av-buffer/tmpFilesArchives/clamav-0.103.6-1.fc36/usr/bin/clamdscan: Can't access file ERROR
> > Mon Nov  7 13:50:21 2022 -> /data/av-buffer/tmpFilesArchives/clamav-0.103.6-1.fc36/usr/bin/clamconf: Can't access file ERROR
> > Mon Nov  7 13:50:21 2022 -> /data/av-buffer/tmpFilesArchives/clamav-0.103.6-1.fc36/usr/bin/clamdscan: Can't access file ERROR
> > Mon Nov  7 13:50:21 2022 -> /data/av-buffer/tmpFilesArchives/clamav-0.103.6-1.fc36/usr/bin/clamdtop: Can't access file ERROR
>
> Can you confirm that the above log extract shows exactly five lines of
> the log?  This is to allow tracking exactly what code in the source
> actually wrote those log lines.  From my reading of the source code I
> would not expect to see 'newline' characters between the filename and
> the text of the message "Can't access ..." but you seem to have them
> in your mail.
>
> > Basically, all the files that we try to scan are triggering the above
> > error. For some files though the scan fives an "OK" and not above
> > error message. However, we fail to see any system / correlation for
> > which files the scans fail and for which the scans are successful. It
> > seems rather random.
>
> Which do you mean:
>
> (1) it's random whether scanning any particular file will cause the
> error message or not  or
>
> (2) scanning some files does not cause the error message, and scanning
> these same files never causes the error message; scanning other files
> always causes the error message; but you see no common factors which
> link (or differentiate) the two sets of files?
>
> > Below you can find the output of clamconf -n:
> > ...
>
> Can you explain how you came to be using all the non-default numbers?
> Some of them look very optimistic to me.
>
> > MaxThreads = "30"
>
> This is on the high side, I believe the default is 10.
>
> > MaxQueue = "200"
>
> Ditto, default 100.
>
> > ExcludePath = ".*\.nc$", ".*\.bin$", ".*\.xml$", ".*\.hdf$", ".*\.h5$"
>
> This might deserve closer inspection than I can give it but I don't
> think it's relevant to the issue.
>
> > MaxDirectoryRecursion = "200"
>
> Default 15.
>
> > FollowDirectorySymlinks = "yes"
> > FollowFileSymlinks = "yes"
>
> Both default no.
>
> Might be an issue if you're crossing filesystems.  Are you?
>
> > MaxScanTime = "1200000"
>
> Twenty minutes; default 12 seconds.  It won't be your issue, but are
> you sure you want to do that?
>
> > MaxScanSize = "4194304000"
> > MaxFileSize = "4194304000"
>
> These numbers are wishful thinking.  The defaults are 100M and 25M
> respectively.  ClamAV cannot yet handle files bigger than 2GB, that's
> clear in the 'man' page for clamd.conf if you'd like to look at it.
>
> > MaxRecursion = "200"
>
> Default 17.
>
> > MaxFiles = "5000000"
>
> Default 10000
>
> > MaxZipTypeRcg = "5242880"
>
> Again see the 'man' page.  This applies also to
>
> MaxThreads*MaxRecursion  +  MaxQueue  -  MaxThreads  +  6
>
> which for your configuration I calculate to be
>
> 30 * 200 + 200 - 30 + 6 = 6176
>
> which bodes ill if, as is likely, RLIMIT_NOFILE on your system is 1024.
> Check it.
>
> > As mentioned earlier, for all the files that were failed to scan, we
> > tried to check access permissions, whether they exist, etc. pp. Those
> > are regular files with correctly configured ACLs. I also tried to run
> > clamdscan as root but it results in a similar problem.
>
> You didn't answer my question about running clamd as root but I think
> given the non-default lines in your config we're probably beyond that.
>
> > Interestingly, when first escalating privileges via "sudo su" and then
> > running clamdscan against a folder within the home directory of the
> > user from which the privileges were escalated (i.e. foo), we receive
> > the following error:
> >
> > [root at epp-3o-w1 av-scans]# clamdscan -v -c /etc/clamd.d/scan.conf
> > /home/foo/test/
> > /home/foo/test: File path check failure: Permission denied. ERROR
> > /home/foo/test: File path check failure: Permission denied. ERROR
> >
> > ----------- SCAN SUMMARY -----------
> > Infected files: 0
> > Total errors: 2
> > Time: 0.000 sec (0 m 0 s)
> > Start Date: 2022:11:07 13:57:07
> > End Date:   2022:11:07 13:57:07
> >
> > # ls -dlsa /home/foo/test/
> > 0 drwxr-xr-x 2 foo sudo 292 Nov  3 10:35 /home/foo/test/
>
> It seems odd to me that /home/foo/test/ is in group 'sudo'.  Or indeed
> that anything in any user's home directory would be.  Looks to me like
> you've mounted a filesystem which was created by a different system,
> and the different system has a different set of numeric UIDs from the
> system running clamd.  That will always be a muddle, and if it is the
> case you need to sort it out.  It's sysadmin - not a ClamAV problem.
>
> > Unfortunately, due to a very strict configuration management we cannot
> > downgrade to 0.103.6 anymore.
>
> If your configuration management does not permit you to troubleshoot a
> problem with your security software I suggest that management is dumb.
> It wouldn't be the first time.
>
> Perhaps you can find a copy of the configuration which you were using
> for 0.103.6 and compare it with what you're using now.  My feeling is
> that it's a serious problem that you have increased some of the limits
> without any regard for potential consequences - although without more
> information I can't say for sure whether or not that is the, er, root
> cause of your issue.
>
> If you can't reinstall 0.103.6 for testing I suggest you reconfigure
> clamd using defaults for most configurable parameters and try again.
>
> --
>
> 73,
> Ged.
> _______________________________________________
>
> Manage your clamav-users mailing list subscription / unsubscribe:
> https://lists.clamav.net/mailman/listinfo/clamav-users
>
>
> Help us build a comprehensive ClamAV guide:
> https://github.com/Cisco-Talos/clamav-documentation
>
> https://docs.clamav.net/#mailing-lists-and-chat