On Tue 04/Nov/2014 18:30:28 +0100 Shawn Webb wrote: > On Tue, Nov 4, 2014 at 12:27 PM, Alessandro Vesely <[email protected]> wrote: > >> Hi, >> I use libclamav to have a mail filter scan mail. It works fine at mine. >> However, I shared the code with someone and it doesn't work at his --he >> reads in BCC. We both use 0.98.4. We managed to run the same test with >> debug enabled. On his system he got: >> >> LibClamAV debug: Module STATS Off >> LibClamAV debug: pool memory used: 5.890 MB >> LibClamAV debug: No bytecodes loaded, not running builtin test >> LibClamAV debug: in cli_magic_scandesc (reclevel: 0/16) >> LibClamAV debug: Recognized Exim mail file >> LibClamAV debug: Starting cli_scanmail(), recursion = 1 >> LibClamAV debug: in mbox() LibClamAV debug: in cli_magic_scandesc >> (reclevel: 1/16) >> ... >> LibClamAV debug: Recognized ASCII text >> LibClamAV debug: Descriptor[6]: cli_scanraw error Can't allocate memory >> LibClamAV debug: cli_magic_scandesc: returning 20 at line 2893 >> >> While on my system, where it works, I have a cache_check line in the first >> snippet, and no error in the second one: >> >> LibClamAV debug: Module STATS Off >> LibClamAV debug: pool memory used: 5.890 MB >> LibClamAV debug: No bytecodes loaded, not running builtin test >> LibClamAV debug: in cli_magic_scandesc (reclevel: 0/16) >> LibClamAV debug: Recognized Exim mail file >> LibClamAV debug: cache_check: 04d636c6846117fe44a898118e8cc7cb is >> negative >> LibClamAV debug: Starting cli_scanmail(), recursion = 1 >> LibClamAV debug: in mbox() >> ... >> LibClamAV debug: in cli_magic_scandesc (reclevel: 1/16) >> LibClamAV debug: Recognized ASCII text >> LibClamAV debug: cache_check: 7b3120d4da0fe032872cb109c65e76c5 is >> negative >> LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0 >> LibClamAV debug: in cli_scanscript() >> LibClamAV debug: hashtab: Freeing hashset, elements: 0, capacity: 0 >> LibClamAV debug: cli_magic_scandesc: returning 0 at line 2973 >> >> What does the absence of cash_check lines mean? >> >> The test was done on a tiny test database. My module is unable to load a >> real database on his system. cl_load returns CL_EMALFDB in that case. >> Yet, he runs clamd and clamscan without problems. He uses grsecurity. >> I only found this on the subject: >> http://lurker.clamav.net/message/20060619.021837.f9057bb8.en.html >> >> I searched clamscan sources for RLIMIT_AS or RLIMIT_DATA (clamd uses the >> latter). IME, ENOMEM is not always reported correctly, so I wonder if >> CL_EMEM is accurate in this case. >> >> Anyone saw this syndrome before? > > You'll need to call cl_initialize_crypto() before calling cl_init(). This > bug will be fixed in ClamAV 0.98.5 (not yet released, but we have an -rc1 > out) and forward.
That was it! Thank you for your quick and precise reply. How come it works well at mine without calling cl_initialize_crypto()? For anyone using grsecurity, he reported he got this message: libClamAV: Bytecode: disabling JIT because PaX is preventing 'mprotect' access. Which he avoided by running: paxctl -cm /path/to/the/program/using/libclamav Ale _______________________________________________ Help us build a comprehensive ClamAV guide: https://github.com/vrtadmin/clamav-faq http://www.clamav.net/contact.html#ml
