Hello,
I am running Mediawiki 1.19.2 on a CentOS 6.3 box, and have installed the ClamAV 0.97.6 package (using yum). I have also set $wgAntivirus to 'clamav' in my LocalSettings.php file.
However, when trying to upload an image this gave me an error code of 127. (Checking the image locally it passes clamav with no problem.)
I then modified $wgAntivirusSetup to use the absolute pathname to 'clamscan'. This now gives me a 126 error code.
I am now a bit stuck. Not too sure what the problem is. The debug log shows:
============== UploadBase::detectVirus: running virus scan: /usr/bin/clamscan --no-summary '/tmp/phpa5rFd7' wfShellExec: /bin/bash '/var/www/html/mediawiki/bin/ulimit4.sh' 180 102400 102400 '/usr/bin/clamscan --no-summary '''/tmp/phpa5rFd7''' 2>&1' UploadBase::detectVirus: failed to scan /tmp/phpa5rFd7 (code 126). ==============
So 'clamscan' seems to run okay via mediawiki, but fails for some reason. Anyone any ideas? I have been trying to find what the 126 error code actually means, but ClamAV doesn't seem to provide a list of error codes anywhere.
Thanks,
John.
Error 127 is likely a "command not found" (either the clamav or a suitable shell to run it under). Error code 126 may be an "insufficient permission" type of error (see https://moodle.org/mod/forum/discuss.php?d=114926).
Try the steps listed in the last message at:
http://www.gossamer-threads.com/lists/wiki/mediawiki/207889
which appears to discuss almost exactly the same issue you describe.
On 10 October 2012 10:15, John Horne john.horne@plymouth.ac.uk wrote:
Hello,
I am running Mediawiki 1.19.2 on a CentOS 6.3 box, and have installed the ClamAV 0.97.6 package (using yum). I have also set $wgAntivirus to 'clamav' in my LocalSettings.php file.
However, when trying to upload an image this gave me an error code of 127. (Checking the image locally it passes clamav with no problem.)
I then modified $wgAntivirusSetup to use the absolute pathname to 'clamscan'. This now gives me a 126 error code.
I am now a bit stuck. Not too sure what the problem is. The debug log shows:
============== UploadBase::detectVirus: running virus scan: /usr/bin/clamscan --no-summary '/tmp/phpa5rFd7' wfShellExec: /bin/bash '/var/www/html/mediawiki/bin/ulimit4.sh' 180 102400 102400 '/usr/bin/clamscan --no-summary '''/tmp/phpa5rFd7''' 2>&1' UploadBase::detectVirus: failed to scan /tmp/phpa5rFd7 (code 126). ==============
So 'clamscan' seems to run okay via mediawiki, but fails for some reason. Anyone any ideas? I have been trying to find what the 126 error code actually means, but ClamAV doesn't seem to provide a list of error codes anywhere.
Thanks,
John.
-- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Wed, 2012-10-10 at 10:44 -0400, Dave Humphrey wrote:
Error 127 is likely a "command not found" (either the clamav or a suitable shell to run it under). Error code 126 may be an "insufficient permission" type of error (see https://moodle.org/mod/forum/discuss.php?d=114926).
Yes, you are right with both of these.
Try the steps listed in the last message at:
http://www.gossamer-threads.com/lists/wiki/mediawiki/207889
which appears to discuss almost exactly the same issue you describe.
Similar maybe, but I'm using clamscan not clamdscan, and I'm not using a chroot.
What I have done so far is set '$wgDebugToolbar = true;'. This provides a debug toolbar at the bottom of the wiki page. Clicking on 'Debug log' then shows the debug messages. Very handy :-) I also set the $wgAntivirusSetup to just set the 'command', and set 'messagepattern' to '(.*)/sim'. (So comment out the 'codemap' bit.) This will basically match any output text from clamscan and dump it onto the upload wiki page.
Having done that I then disabled SELinux, and could see that clamav was having problems allocating memory. Mediwiki calls a 'ulimit4.sh' script which sets the amount of memory the process can use (default=102400). I set '$wgMaxShellMemory = 1024000;', and I could then upload the file :-) The file itself is small, but the clamav databases are large.
Downside of course is that SELinux was disabled. I have tried setting the SELinux boolean 'httpd_ssi_exec' to true, but that still causes the clamscan to fail, but only gives the output as '1'. Most odd.
John.
I was thinking it sounded like a chroot or mandatory access control issue. If you work out the transition rules for SELinux, please share!
I've been working on getting AppArmor profiles defined for several of the external applications we call. I'll add one for clamav, in case that's an option for anyone.
On Wed, Oct 10, 2012 at 8:25 AM, John Horne john.horne@plymouth.ac.uk wrote:
On Wed, 2012-10-10 at 10:44 -0400, Dave Humphrey wrote:
Error 127 is likely a "command not found" (either the clamav or a suitable shell to run it under). Error code 126 may be an "insufficient permission" type of error (see https://moodle.org/mod/forum/discuss.php?d=114926).
Yes, you are right with both of these.
Try the steps listed in the last message at:
http://www.gossamer-threads.com/lists/wiki/mediawiki/207889
which appears to discuss almost exactly the same issue you describe.
Similar maybe, but I'm using clamscan not clamdscan, and I'm not using a chroot.
What I have done so far is set '$wgDebugToolbar = true;'. This provides a debug toolbar at the bottom of the wiki page. Clicking on 'Debug log' then shows the debug messages. Very handy :-) I also set the $wgAntivirusSetup to just set the 'command', and set 'messagepattern' to '(.*)/sim'. (So comment out the 'codemap' bit.) This will basically match any output text from clamscan and dump it onto the upload wiki page.
Having done that I then disabled SELinux, and could see that clamav was having problems allocating memory. Mediwiki calls a 'ulimit4.sh' script which sets the amount of memory the process can use (default=102400). I set '$wgMaxShellMemory = 1024000;', and I could then upload the file :-) The file itself is small, but the clamav databases are large.
Downside of course is that SELinux was disabled. I have tried setting the SELinux boolean 'httpd_ssi_exec' to true, but that still causes the clamscan to fail, but only gives the output as '1'. Most odd.
John.
-- John Horne Tel: +44 (0)1752 587287 Plymouth University, UK Fax: +44 (0)1752 587001
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
On Wed, 2012-10-10 at 08:55 -0700, Chris Steipp wrote:
I was thinking it sounded like a chroot or mandatory access control issue. If you work out the transition rules for SELinux, please share!
Hello,
Well I finally got this working. However, I needed to create a local policy to do it. To get things working I:
1) Enabled the SELinux boolean 'httpd_ssi_exec'.
2) Based on the 'denied' records being logged by SELinux, installed the following policy:
================================================================== module mediawiki_local 1.0;
require { type httpd_tmp_t; type clamscan_exec_t; type httpd_sys_script_t; type httpd_t; type clamscan_t; class process setrlimit; class fifo_file { write getattr }; class file { read getattr open }; }
#============= clamscan_t ============== allow clamscan_t httpd_t:fifo_file { write getattr }; allow clamscan_t httpd_tmp_t:file { read getattr open };
#============= httpd_sys_script_t ============== allow httpd_sys_script_t self:process setrlimit;
#============= httpd_t ============== allow httpd_t clamscan_exec_t:file { read getattr }; ==================================================================
Other than raising the value of '$wgMaxShellMemory' in LocalSettings.php, as mentioned before, that was it.
However, I suspect that others may have different issues depending on where Mediawiki is actually installed. For example, installing it in '/home' may well require setting various SELinux attributes to allow Apache to access the wiki files. In our case I installed Mediawiki directly into '/var/www/html'. This should, and seems to have, avoided most problems with Apache running things.
John.
mediawiki-l@lists.wikimedia.org