Hi Sebastian, On 30.05.2015 21:35, Sebastian Andrzej Siewior wrote: > On Sat, May 30, 2015 at 03:06:33PM +0200, Andreas Cadhalpun wrote: >> I found the reason, why clam_cache_emax.tgz is not detected by clamdscan: >> It hits the MaxRecursion limit of 10, while it needs 17 recursions. > > 16 to be exact.
Indeed. > Just verified it on Wheezy. The testsuite passes and since I > don't see a config file supplied for the testsuite I checked the source for > the default value and this is > > libclamav/default.h:#define CLI_DEFAULT_MAXRECLEVEL 16 Ah, I see. > This is also what the manpage for clamd.conf claims to be the default. Yes, it's just that the clamd.conf.sample contains: # Nested archives are scanned recursively, e.g. if a Zip archive contains a RAR # file, all files within it will also be scanned. This options specifies how # deeply the process should be continued. # Note: setting this limit too high may result in severe damage to the system. # Default: 16 #MaxRecursion 10 So that's where the 10 came from. > It also > says "setting it too high may result in severe damage to the system" failing > to describe the "why" here… I guess if one sets it to 100000000 and comes across a particularly malicious file it can exhaust RAM/disk space and thus cause all kinds of problems. > I'm fine with raising the default value in the config file to 16 since it is > clamd's default value. I think that would be the best way forward. > We also could drop all "default" values from config > file so they would adjust on their own if upstream changes them. Not sure if > this possible with the current debconf setup. I think leaving the options with default settings in the config file makes it a lot more self-explanatory. > I guess in that case we could > try to create clamd.conf from the default.h. We could try this, but it might be a bit overkill. Best regards, Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
