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(a)gmail.com>
Apparently from: mediawiki-l-bounces(a)lists.wikimedia.org
To: mediawiki-l(a)lists.wikimedia.org
Subject: Re: [Mediawiki-l] Setting up clamav for chrooted apache
Date: Mon, 30 Aug 2010 14:09:54 +0200
tojja(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l