6

Not sure what's going on here. I've installed clamav, clamav-freshclam and clamav-daemon to run automated scans (using cron) on my machine running Ubuntu Desktop 10.04 LTS x64.

Unfortunately, clamdscan refuses to scan anything. This is the output I receive every time I try:

root@uhs:/raid/Share/Public/# clamdscan -v /raid/Share/Public/
/raid/Share/Public: lstat() failed: Permission denied. ERROR

----------- SCAN SUMMARY -----------
Infected files: 0
Total errors: 1
Time: 0.004 sec (0 m 0 s)
root@uhs:/raid/Share/Public/#

/raid/Share/Public has 777 permissions, and the clamav-daemon user clamav has been added to both the admin and root groups. I get the same error no matter what files or directories I try to scan.

I even ran dpkg-reconfigure clamav-base and made the daemon user root to see if that would help (which it didn't). And I have of course run service clamav-daemon restart in between all of these changes.

I'm aware of the cat file_name | clamdscan - option, but I need to be able to scan whole directories recursively, so obviously this won't work.

What am I doing wrong? Can I use clamdscan?

Thank you for any help.

Update

Output of sudo -u clamav stat /raid/Share/Public/:

root@uhs:/raid/Share/Public# sudo -u clamav stat /raid/Share/Public/
  File: `/raid/Share/Public/'
  Size: 6           Blocks: 0          IO Block: 4096   directory
Device: 900h/2304d  Inode: 54526208    Links: 2
Access: (0777/drwxrwxrwx)  Uid: ( 1000/awensley)   Gid: (  120/   admin)
Access: 2011-01-19 01:00:00.304365306 -0600
Modify: 2011-01-18 22:47:06.793592673 -0600
Change: 2011-01-19 00:42:52.023813550 -0600
root@uhs:/raid/Share/Public#

Update 2

I have this exact same problem on 5 separate Ubuntu 10.04 machines; 3 of them servers. So either I'm missing something or there's a real problem here.

Update 3

I've submitted this as a bug report on Launchpad

Community
  • 1
Andrew Ensley
  • 762
  • 1
    Try: sudo -u clamav stat /raid/Share/Public/ , post the output. – João Pinto Jan 19 '11 at 18:08
  • I've added the output from that command as requested. The directory is empty, I'm just using it for testing this functionality. – Andrew Ensley Jan 19 '11 at 21:04
  • Does dmesg show anything unusual? – Kees Cook Jan 27 '11 at 20:03
  • I've monitored dmesg with tail -f /var/log/dmesg when attempting to run scans. Nothing goes to that log when I receive the error. Should I be watching during other events as well? – Andrew Ensley Jan 28 '11 at 00:01
  • I know you said "I'm aware of the cat file_name | clamdscan - option, but I need to be able to scan whole directories recursively, so obviously this won't work." but what about "find /raid/Share/Public/ | clamdscan"...doesn't fix the problem but it's a workaround – RobotHumans Jan 30 '11 at 14:03
  • sorry, slight oversight that command isn't a cut and paster, but you can use find to recursively list and grep '/' -exec or something similar to get it done – RobotHumans Jan 30 '11 at 16:21

1 Answers1

5

Elsewhere, I've seen that AppArmor or SELinux can cause problems for clamdscan.

If you run sudo aa-complain clamd and the re-scan works, that's probably your issue. (Be sure to re-enable it with sudo aa-enforce clamd.)

To temporarily disable SELinux, which I haven't run on Ubuntu, you can try echo 0 > /selinux/enforce . We can follow up with that if you're running SELinux.

update: Here's a very interesting thread from launchpad: https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/450250 . I would follow Jamie Strandboge's comments there to eliminate AppArmor profiles as the culprit.

If these aren't applicable the hack that springs to mind is piping a directory to standard output via tar, and feeding that into clamdscan (which is a variation on what you've mentioned for a single file). I think that would look something like : 

 tar -cvf --to-stdout /somedirectory | clamdscan -

You should be able to get the most recent packaged version of clamav from the Ubuntu Clamav team from their ppa : https://launchpad.net/~ubuntu-clamav/+archive/ppa

Also, from the ClamAV site: "If you are going to submit a bug report, always check it against the latest development code ." (Assuming you haven't already done this) You'll have to pull that code manually from their Git repository and compile it.

For bug reporting on the Ubuntu packages, please see http://askubuntu.com...how-do-i-report-a-bug .

=======

One thing to note, is that as far as I can tell, it is clamscan and not clamdscan which is supposed to just work unproblematically in your home directory.

Ubuntu presents some possible complication (with the very desirable security increase) by having apparmor turned on by default.

(clamdscan requires the clamav daemon to be running -- clamscan, more of an ad-hoc user-oriented package, does not. With the additional features of clamdscan/clamd, there is added complexity overhead.)

Yet, against that, the bug for clamdscan and apparmor mentioned in the bug from this post should have been corrected by the time of the current package.

Updated attempts to reproduce and resolve

I don't think I can completely reproduce your environment or control for user error (definitely mine and possibly yours), however I've reproduced what I think is the same issue under the same version of clamav you have.

Additionally, I've downloaded the latest code from the git repository, compiled and installed it, and still have the issue.

I don't have SELinux, but I do have AppArmor. Have I correctly accounted for that? I'm not 100%. I still get the permission denied errors after turning off AppArmor though.

=======

Community
  • 1
belacqua
  • 23,120
  • I thought I had it with the apparmor profiles. I added /raid/ r, /raid/** r, to /etc/apparmor.d/usr.sbin.clamd and restarted apparmor and clamav-daemon, but ended up with the exact same problem. I even stopped apparmor completely with service apparmor teardown (the stop option doesn't unload profiles), restarted clamav-daemon, and... same problem. I'm thinking maybe it's selinux or a bug now. I didn't fully understand how to use the command to disable selinux, so I'm not sure if it worked. – Andrew Ensley Jan 25 '11 at 18:38
  • Nevermind, I just found this article: http://www.thegeekstuff.com/2009/06/how-to-disable-selinux-redhat-fedora-debian-unix/ and verified that I did disable selinux properly. I still have the same problem. I think this is a bug now because I also noted that even with the default installation of clamav-daemon (after purging all clamav packages completely), I can't even scan my home directory, which IS supposed to "just work" according to that bug report. – Andrew Ensley Jan 25 '11 at 18:44
  • I have ClamAV 0.96.5/12569/Tue Jan 25 10:13:26 2011 – Andrew Ensley Jan 25 '11 at 22:49
  • So, this is a bug right? I can't even scan my own home directory, and the entries to allow for that in the apparmor profile were already there when I looked at it. – Andrew Ensley Jan 26 '11 at 17:56
  • As far as I can tell, it does look like a bug. I am not confident in isolating the component at fault, though. I'm updating my answer with some steps I took in an attempt to reproduce and resolve. – belacqua Jan 26 '11 at 18:53
  • For now, I think it would be helpful to send this as an ubuntu bug. Please try running ubuntu-bug clamav-base or possibly against clamav-daemon. Let us know -- I'll add myself to the bug. – belacqua Jan 26 '11 at 18:56
  • In response to your attempt to reproduce the error, I had both selinux and apparmor completely disabled and clamdscan still didn't work. Also, the apparmor profile is /etc/apparmor.d/usr.sbin.clamd, ending with clamd (which implies daemon, though I could be wrong). I'm going to try to submit the bug now. As far as I can tell, clamdscan in Ubuntu 10.04 doesn't do jack. – Andrew Ensley Jan 26 '11 at 23:10
  • Bug reported: https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/708395 – Andrew Ensley Jan 26 '11 at 23:48
  • Please, never use "service apparmor teardown", just stop individual profiles, like this: "aa-complain clamd" – Kees Cook Jan 27 '11 at 19:57
  • @Kees You mean as an apparmor best practice? (We should have a QA post for that!) However, in some cases we don't know what package is presenting the problem. Teardown is the equivalent of completely removing an ACL on a firewall instead of tinkering with an individual src/dst/port rule -- something you do for a moment before reapplying the entire set of protections. Certainly you don't want to run that way, but success or failure gives you a clear idea of a major component that should be targeted or eliminated as a possible culprit. Or is there some more dire consequence of teardown? – belacqua Jan 27 '11 at 20:24
  • @Kees -- here's the 'best practices' post: http://askubuntu.com/questions/23577/i-need-to-troubleshoot-apparmor-but-ive-heard-that-using-the-teardown-method – belacqua Jan 27 '11 at 20:32
  • Bounty awarded. Thanks for your help. I gained a lot of info about Apparmor through this process that I had no clue about before. Hopefully the devs can figure out the rest of the issue. – Andrew Ensley Jan 30 '11 at 23:26