> [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 <[email protected]> on behalf of G.W. Haywood via clamav-users <[email protected]> Sent: Monday, November 7, 2022 8:59 AM To: An Schall via clamav-users <[email protected]> Cc: G.W. Haywood <[email protected]> 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@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
_______________________________________________ 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
