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

Tue Nov 8 22:55:22 UTC 2022

> [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.]

Thanks. Perhaps we should add this issue to https://github.com/Cisco-Talos/clamav/issues/731

Micah Snyder
ClamAV Development
Talos
Cisco Systems, Inc.

________________________________
From: clamav-users <clamav-users-bounces at lists.clamav.net> on behalf of G.W. Haywood via clamav-users <clamav-users at lists.clamav.net>
Sent: Monday, November 7, 2022 8:59 AM
To: An Schall via clamav-users <clamav-users at lists.clamav.net>
Cc: G.W. Haywood <clamav at jubileegroup.co.uk>
Subject: Re: [clamav-users] Can't access file ERROR - clamdscan - 0.103.7-1

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clamav.net/pipermail/clamav-users/attachments/20221108/2ce0dc77/attachment.htm>