mainDazuko - Support: sr #105836, Dazuko-2.3.3 on_close event problem


sr #105836: Dazuko-2.3.3 on_close event problem

Submitter:  Ceejay Cervantes <ceejay949>
Submitted:  Mon 23 Apr 2007 01:30:08 AM UTC
Assigned to:  None Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup

Fri 27 Apr 2007 04:07:09 PM UTC, comment #3: 

The fact that your system performance is slow is probably due to the speed of the ClamAV engine. You can help this by only scanning directories that you know to be read-write. This will reduce the amount of files that ClamAV must scan.

The shutdown-freezing problem is probably because the ClamAV service is not being shut down soon enough. The FAQ may have more information for you about this:

John Ogness <ogman>
Group administrator
Mon 23 Apr 2007 03:17:38 PM UTC, comment #2: 

Thank you very much for the explanation. Now, I fully understand the process.
I’m sorry for not explaining clearly my problem.

By the way I have another concern. I noticed that my PC slows down when I set / in the IncludePath of Clamuko. I tried putting /proc on the ExcludePath of Clamuko but the performance is still the same.  Also, the PC does not respond when I shutdown it. It seems that the system freezes. As an alternative, is it ok to put only shared directories on the IncludePath and schedule a daily full system scan?  Any suggestions would be really helpful?

Thank you very much.

Ceejay Cervantes <ceejay949>
Mon 23 Apr 2007 01:16:11 PM UTC, comment #1: 

Perhaps you should begin by explaining what you expect to happen for close events.

When you copy a file over (for example, a virus), there are 3 basic steps that happen:

1. The target file is opened. Dazuko catches this event. (At this moment, the file is empty, so a virus-scanner would not block this.)

2. The contents of the virus are written to the new file. This is done using write operations. Dazuko does not monitor these operations. (By the end of this step, the virus is completely copied and available.)

3. The new file is closed. This is a technical step that exists so that the operating system can free resources. However, it is not related to the contents of the file. (Dazuko reacts to this event and an anti-virus scanner provides the appropriate notification. It makes no sense to block this event, because the contents of the file already exist (from step 2). Blocking this event would only lead to resource leaks in the operating system.)

If you feel uncomfortable letting viruses sit on the hard drive, you can probably configure your anti-virus scanner to move the file to some other quarentine directory. This would have the effect of the file being removed after it was copied.

However, keep in mind that the "close" events do not offer realtime protection. They are simply there as a convenience to offer more events. It is the "open" event that will work most effectively and reliably for realtime protection. (This is because the contents of the file are written in step 2.)

If you want an on-access scanner that performs scanning with each read/write of a block of data, the only solution I am aware of is avfs. But I believe this is only a research project and is not supported by professional anti-virus companies.

John Ogness <ogman>
Group administrator
Mon 23 Apr 2007 01:30:08 AM UTC, original submission:  

I compiled dazuko 2.3.3 on kernel 2.6.9 with options
./configure --sct-readonly --enable-syscalls --mapfile=/boot/

My problem is on_close event does not work well.
on_open and on_exec events denies access to the file, but when i save a copy of an infected file to a protected directory. I only received notifications that there is a virus and the infected file is saved. Am I missing something?

Ceejay Cervantes <ceejay949>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ogman (Posted a comment)
  • -email is unavailable- added by ceejay949 (Submitted the item)

    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-03-19 ogman Assigned toogman None
    2007-04-23 ogman Assigned toNone ogman

    Back to the top

    Powered by Savane 3.13-4b48.
    Corresponding source code