Thanks for the suggestion Platonides. After some digging around it appears that I have the same problem identified at http://readlist.com/lists/lists.clamav.net/clamav-users/1/6452.html which looks to be a problem with clamdscan passing a path within the chroot to clamd which typically won't exist. To test this one can 'touch /var/www/tmp/test' then 'chroot -u www /var/www /usr/local/bin/clamdscan /tmp/test' and it will fail with '/tmp/test: lstat() failed: No such file or directory. ERROR'. Now if one executes 'touch /tmp/test' and tries to scan within the chroot again it will work (barring any permissions problems). What I need is a way to tell clamd to append the chroot path onto the path supplied by clamdscan or trick clamdscan to not check for file existence since clamdscan checks if the path is valid inside the chroot then passes the path directly to clamd.
-------- Original Message -------- From: Platonides Platonides@gmail.com Apparently from: mediawiki-l-bounces@lists.wikimedia.org To: mediawiki-l@lists.wikimedia.org Subject: Re: [Mediawiki-l] Setting up clamav for chrooted apache Date: Mon, 30 Aug 2010 14:09:54 +0200
tojja@Safe-mail.net wrote:
Hi, I am experiencing a problem running clamav on an OpenBSD machine. Apache comes chrooted by default (a configuration I want to keep) therefore when the apache user tries to scan a file it finds that no executable named clamscan or clamdscan is inside the chroot. Now I've tried to copy/synlink the executable(s) and the dependent files under the chroot and execute the scan however in my debug log file I always get:
UploadBase::detectVirus: running virus scan: /usr/local/bin/clamdscan --no-summary '/tmp/phpqkflgiwo' 2>&1 wfShellExec: /usr/local/bin/clamdscan --no-summary '/tmp/phpqkflgiwo' 2>&1 Possibly missing executable file: /usr/local/bin/clamdscan --no-summary '/tmp/phpqkflgiwo' 2>&1 UploadBase::detectVirus: failed to scan /tmp/phpqkflgiwo (code 127).
From the look of it it can't see the executable to even try to scan. If the apache user (www) is running the scan and the same user is executing the scan then permissions of usr/local/bin/clamdscan is 555 (all the way through the path) then it seems it should at least be able to find the file. An odd but seemingly unrelated problem is that the temporary directory is set to /tmp (within the chroot) even though $wgTmpDirectory is set to /htdocs/wiki/images and in php settings they're set to /htdocs/temp. Trying to compile clamav with the --prefix and --exec-prefix options set inside the chroot doesn't result in the program being installed inside the chroot.
If I could just tell clamdscan to talk with the clamd socket that would be nice but it doesn't appear to be practical. It looks like installing clamav inside the chroot path should help but it isn't working as I had hoped. I made a test php script that executes the shell command that mediawiki does (from the wfShellExec function in GlobalFunctions.php) and directly put the desired command for a test file within the chroot and it still behaves the same way when invoked directly on the command line "php test.php". If someone has any suggestions on how to get these programs to work together I'd like to see them. Thanks in advance!
You have copied /usr/local/bin/clamdscan as /var/www/usr/local/bin/clamdscan ? What about the libraries ? You will also need a /var/www/etc/clamav/clamd.conf And have the socket inside the chroot...
I think the best would be to chroot yourself there and try to run it from command line seeing what errors it gives you.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
tojja@Safe-mail.net wrote:
Thanks for the suggestion Platonides. After some digging around it appears that I have the same problem identified at http://readlist.com/lists/lists.clamav.net/clamav-users/1/6452.html which looks to be a problem with clamdscan passing a path within the chroot to clamd which typically won't exist. To test this one can 'touch /var/www/tmp/test' then 'chroot -u www /var/www /usr/local/bin/clamdscan /tmp/test' and it will fail with '/tmp/test: lstat() failed: No such file or directory. ERROR'. Now if one executes 'touch /tmp/test' and tries to scan within the chroot again it will work (barring any permissions problems). What I need is a way to tell clamd to append the chroot path onto the path supplied by clamdscan or trick clamdscan to not check for file existence since clamdscan check s if the path is valid inside the chroot then passes the path directly to clamd.
Try passing --fdpass or --stream to clamdscan.
mediawiki-l@lists.wikimedia.org