HTTP Anti-Virus Proxy

I'm using ClamAV 0.91.2 & havp 0.86 from Debian lenny/sid.
While I am able to use the ClamAV Socket Scanner (clamd) without problem, I am not able to use the ClamAV Library Scanner (libclamav).
When it is enabled and I restart havp, I get the following error :

LibClamAV Error: cli_load(): Can't open file /var/lib/clamav/daily.inc/daily.cfg

This appears to be a permission problem and sure enough if I make all the the virus DB files in /var/lib/clamav world-readable, the problem goes away and havp operates succesfully.
However my default/system umask is set such that read permissions for only the owner and group are granted by default upon new file creation (and I want to keep it that way!). This means that when freshclam updates any virus database file, its' permissions are reset to 0640 (-rw-r-----) causing havp to fail on the next DB reload.

All virus DB files belong to the "clamav" user & group (which is also the user that clamd is running as). Havp is running as user "havp".
Adding user "havp" to the "clamav" group strangely does not solve the problem.

I am at a loss as to how to solve this problem, so any help that you can provide would be greatly appreciated.

Regards

Os

Just a guess, but I think HAVP needs some code to actually use/activate the "extra" groups. I'll see if I can fix it.

In the mean time, why not just add the "umask 022" command before freshclam call..

Cheers,
Henrik

Henrik, thanks for the quick response.

I am not sure how to do what you've suggested because FreshClam is a daemon and not a script run as a cron job. The daemon is a binary and its associated configuration file does not provide a facility for executing commands before it updates the virus DB files.

Are you suggesting adding "umask 022" to the initial freshclam daemon start-up script (/etc/init.d/clamav-freshclam )?

I guess one alternative would be to use the "OnUpdateExecute" command in freshclam.conf to run a permissions update on the virus DB files after they have been updated and before I force a HAVP reload.

Back to the actual problem - I don't quite understand why HAVP would need extra code to access files through group permission, I thought this was handled by the filesystem.
Is HAVP actually trying to read the virus DB files as the user set in the /etc/havp/havp.config file?

Thanks for your help

regards

Os

Sure.



Users have main group and supplementary groups. That's why there is "AllowSupplementaryGroups" in clamd.conf to enable it in ClamAV, they are not automatically used.

You could change the main group of HAVP too, then it's used directly (GROUP clamav).

Cheers,
Henrik

<DELETE>

Thanks. I've learnt something new today

Regards

Os

I added "umask 022" to the initial freshclam daemon start-up script (/etc/init.d/clamav-freshclam) and for a day or two it seemed to have been a good temporary fix.

However, recently, I have found that when certain /var/lib/clamav/ files are updated (possibly deleted & re-created) their permissions reset to 0640 (-rw-r-----) in spite of the changes. At first it was only /var/lib/clamav/daily.inc/daily.info which didn't affect the HAVP operation, but then also /var/lib/clamav/daily.inc/daily.wdb which caused HAVP to crash with a virus DB reload failure. Looking at the timestamps for individual files it bizarrely seems that other files are being updated without having their permissions reset.

So right now I am going to try to use the "OnUpdateExecute" command in freshclam.conf to run a permissions update on the virus DB files after they have been updated and before I force a HAVP reload.

Regards

Os

Despite adding the following commands to /etc/clamav/freshclam.conf

OnUpdateExecute chmod o+r /var/lib/clamav/main.cvd
OnUpdateExecute chmod o+r /var/lib/clamav/main.inc/*
OnUpdateExecute chmod o+r /var/lib/clamav/daily.inc/*
OnUpdateExecute invoke-rc.d havp reload

certain /var/lib/clamav/ files are being updated (possibly deleted & re-created) with their permissions reset to 0640 (-rw-r-----)!
Sometimes it is /var/lib/clamav/daily.inc/daily.wdb, other times it is /var/lib/clamav/daily.inc/daily.ndb or /var/lib/clamav/daily.inc/daily.ndu. In any case the effect is the same - HAVP crashes with a virus DB reload failure.

I can only conclude that these files are either modified by processes other than the freshclam update process or modified by freshclam even when they don't need to be updated and the OnUpdateExecute commands are not triggered.

Hege - any luck with the supplementary group usage code fix?

Regards

Os

Groups should work now..

http://havp.hege.li/download/havp-0.87pre.tar.gz

OK.

I'll give it a try.

Can I just compile it and replace my current executable without doing a full install?

Are there any new config file options?

Os

Yes.



ChangeLog says: TRICKLINGBYTES

Fantastic, it works like a dream!

Thank you very much.

One question: the new HAVP 0.87pre executable appears to be 6-7 times larger than my old debian HAVP 0.86 executable.

2138613 bytes vs. 325728 bytes.

Is this because of the new code or have the debian packagers done something clever?

Os

If you strip(1) the binary, it will get smaller. New versions of HAVP don't do this on install, since it makes debugging harder by default.

Great! Thanks - strips to 318640 bytes.

Os

btw - would I be right in saying, that if Freshclam is being run as user "clamav" and HAVP is being run as user "havp", there is no way that the command "OnUpdateExecute /etc/init.d/havp reload" in freshclam.conf can work?

(it is silently failing for me at the moment)