Mailing List Archive: ClamAV: users

libclamav cl_scan* & strings (0.60)

Index | Next | Previous | View Threaded

julienbenoist at altern

Aug 6, 2003, 6:16 AM

Post #1 of 6 (772 views)
Permalink

*libclamav cl_scan & strings (0.60)**

Is there a trivial way to scan strings *with* CL_ARCHIVE & CL_MAIL support
?

As cl_clambuff() doesnt support these features, i tried to cheat with a
UNIX pipe :

char *buffer;
int pfd[2];

/* ...
* buffer malloced & contains data
* ...
*/

pipe(pfd);
write(pfd[1],buffer,strlen(buffer));
close(pfd[1]);

/* ...
* various libclamav initialisations
* ...
*/

if((ret = cl_scandesc(fd, &virusname, &size, root, &limits,
CL_ARCHIVE | CL_MAIL)) == CL_VIRUS) {
syslog(LOG_DEBUG,"Detected %s virus", virusname);
} else {
syslog(LOG_DEBUG,"No virus dected");
if(ret != CL_CLEAN)
syslog(LOG_CRIT,"Error: %s\n", cl_perror(ret));
}

The following never worked. cl_scandesc() never returns CL_VIRUS,
throught, it seamed to detect file types, as cl_perror() would return "RAR
module failure" with one of the files in the test/ dir.

--
Julien Benoist

tk at mat

Aug 6, 2003, 10:34 AM

Post #2 of 6 (747 views)
Permalink

*Re: libclamav cl_scan & strings (0.60)** [In reply to]

On Wed, 6 Aug 2003 15:05:46 +0000 (UTC)
Julien Benoist <julienbenoist [at] altern> wrote:

>
> Is there a trivial way to scan strings *with* CL_ARCHIVE & CL_MAIL support
> ?

No, there isn't.

> pipe(pfd);
> write(pfd[1],buffer,strlen(buffer));
> close(pfd[1]);

First thing - the code above is broken. When working with a binary data, strlen
will return a false size of the buffer, because it's almost sure there's the
terminating \0 character in the buffer.

You should save all data to a temporary file and run cl_scandesc on it.

> throught, it seamed to detect file types, as cl_perror() would return "RAR
> module failure" with one of the files in the test/ dir.

rarfail.rar is a winrar 3.0 archive and the internal rar library can't handle it.
Only clamscan with --unrar (and unrar 3.0 installed in the system) can scan it.

Best regards,
Tomasz Kojm
--
oo ..... zolw [at] konarski
(\/)\......... http://www.konarski.edu.pl/~zolw
\..........._ I nie zapomnij kliknac w brzuszek...
//\ /\\ <- C. Amboinensis www.pajacyk.pl

julienbenoist at altern

Aug 6, 2003, 1:14 PM

Post #3 of 6 (746 views)
Permalink

*Re: libclamav cl_scan & strings (0.60)** [In reply to]

On Wed, 6 Aug 2003, Tomasz Kojm wrote:
>
> On Wed, 6 Aug 2003 15:05:46 +0000 (UTC)
> Julien Benoist <julienbenoist [at] altern> wrote:
>
> >
> > Is there a trivial way to scan strings *with* CL_ARCHIVE & CL_MAIL support
> > ?
>
> No, there isn't.
>
> > pipe(pfd);
> > write(pfd[1],buffer,strlen(buffer));
> > close(pfd[1]);
>
> First thing - the code above is broken. When working with a binary data, strlen
> will return a false size of the buffer, because it's almost sure there's the
> terminating \0 character in the buffer.

Hmmm, I forgot to tell... this piece of code will only scan mails (where
data is MIME encoded).

>
> You should save all data to a temporary file and run cl_scandesc on it.

Agreed, but i actually wanted to avoid it for performance reasons.

>
> > throught, it seamed to detect file types, as cl_perror() would return "RAR
> > module failure" with one of the files in the test/ dir.
>
> rarfail.rar is a winrar 3.0 archive and the internal rar library can't handle it.

ok for the rarfail.rar file, but cl_perror() also returned some "ZIP
module failure" while scanning some other files (it did work with ex1.c).
Throught, in the above code, replacing this fd to pipe by a fd to file
worked pretty well.

kind regards,

Julien Benoist

tk at mat

Aug 6, 2003, 2:26 PM

Post #4 of 6 (751 views)
Permalink

*Re: libclamav cl_scan & strings (0.60)** [In reply to]

On Wed, 6 Aug 2003 22:10:51 +0000 (UTC)
Julien Benoist <julienbenoist [at] altern> wrote:

> >
> > You should save all data to a temporary file and run cl_scandesc on it.
>
> Agreed, but i actually wanted to avoid it for performance reasons.

Oh, I think it's a missed idea - what about really big attachments ?

> ok for the rarfail.rar file, but cl_perror() also returned some "ZIP
> module failure" while scanning some other files (it did work with ex1.c).
> Throught, in the above code, replacing this fd to pipe by a fd to file
> worked pretty well.

descriptor has to be seek()able

Best regards,
Tomasz Kojm
--
oo ..... zolw [at] konarski
(\/)\......... http://www.konarski.edu.pl/~zolw
\..........._ I nie zapomnij kliknac w brzuszek...
//\ /\\ <- C. Amboinensis www.pajacyk.pl

julienbenoist at altern

Aug 6, 2003, 3:09 PM

Post #5 of 6 (745 views)
Permalink

*Re: libclamav cl_scan & strings (0.60)** [In reply to]

On Wed, 6 Aug 2003, Tomasz Kojm wrote:
> > >
> > > You should save all data to a temporary file and run cl_scandesc on it.
> >
> > Agreed, but i actually wanted to avoid it for performance reasons.
>
> Oh, I think it's a missed idea - what about really big attachments ?

Our system has a maximum attachment size, but i believe this idea is not
that good :D

>
> > ok for the rarfail.rar file, but cl_perror() also returned some "ZIP
> > module failure" while scanning some other files (it did work with ex1.c).
> > Throught, in the above code, replacing this fd to pipe by a fd to file
> > worked pretty well.
>
> descriptor has to be seek()able

i see, and seek()ability of pipes are OS related ?

Anyway, the performance issue i'm talking about is the following: some
postifx will forward mails to some filterservers via a tcp socket, these
servers will perform antispam & antivirus checks, and return the mail with
enriched headers. I'm just afraid that writing all of these stuff to the
disk would be load intensive, as we have a huge ammount of incoming mails
per second.

But I'll go this way and post to the list to tell you about how it runs.

Thanks a lot for your help Tomasz

kind regards

Julien Benoist

kgc at sonic

Aug 6, 2003, 3:30 PM

Post #6 of 6 (749 views)
Permalink

*Re: libclamav cl_scan & strings (0.60)** [In reply to]

On Thu, Aug 07, 2003 at 12:02:00AM +0000, Julien Benoist wrote:
> On Wed, 6 Aug 2003, Tomasz Kojm wrote:
> > > >
> > > > You should save all data to a temporary file and run cl_scandesc on it.
> > >
> > > Agreed, but i actually wanted to avoid it for performance reasons.
> >
> > Oh, I think it's a missed idea - what about really big attachments ?
>
> Our system has a maximum attachment size, but i believe this idea is not
> that good :D
>
> >
> > > ok for the rarfail.rar file, but cl_perror() also returned some "ZIP
> > > module failure" while scanning some other files (it did work with ex1.c).
> > > Throught, in the above code, replacing this fd to pipe by a fd to file
> > > worked pretty well.
> >
> > descriptor has to be seek()able
>
> i see, and seek()ability of pipes are OS related ?
>
> Anyway, the performance issue i'm talking about is the following: some
> postifx will forward mails to some filterservers via a tcp socket, these
> servers will perform antispam & antivirus checks, and return the mail with
> enriched headers. I'm just afraid that writing all of these stuff to the
> disk would be load intensive, as we have a huge ammount of incoming mails
> per second.
>
> But I'll go this way and post to the list to tell you about how it runs.

In similar situations here we try to use tmpfs, /dev/shm, etc, for temp
file storage. You'll need to have enough ram, but you'll keep the tempfiles
off of your disk subsystem which will probably be the bottleneck.

--
Kelsey Cummings - kgc [at] sonic sonic.net, inc.
System Administrator 2260 Apollo Way
707.522.1000 (Voice) Santa Rosa, CA 95407
707.547.2199 (Fax) http://www.sonic.net/
Fingerprint = D5F9 667F 5D32 7347 0B79 8DB7 2B42 86B6 4E2C 3896

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads