Re: [Dazuko-devel] 2.0.6 released

[Calin A. Culianu]

On Tue, 22 Mar 2005, John Ogness wrote:

> Calin A. Culianu wrote:
>
> Hi,
>
> The only changes from 2.0.5 to 2.0.6 have to do with fixes in LSM for the 
> Linux 2.6 kernel. This means you. :)
>
> In 2.0.5 there was an ugly typo in the LSM stacking code. I do not quite 
> understand how 2.0.5 is able to compile. The possible side-effects of this 
> error would be that capabilities might not work correctly. But that is all.

Does Dazuko use capabilities in order to intercept file access events?

> There were no changes from 2.0.5 to 2.0.6 that would fix a lockup. Lockups 
> can occur if your registered application blocks on some resource and there 
> are no other registered applications in the same group to continue the file 
> access control.

Yes.. it's possible that my application was entering a deadlock situation. 
It actually did really crazy things like interact with another daemon 
process via a unix socket.  That process was also generating dazuko 
events, and I suspect in some situations if my thread pool limit is 
reached then basically everyone is waiting for a new dazuko access to get 
picked up, but it never comes since my threads are maxed out... or 
something like that.  Anyway I reworked it so that the daemon process 
doesn't generate dazuko events.

> It is better to register multiple processes or threads under the same group 
> name and let them work together. This can really help if your application 
> wants to do blocking-type actions (such a file I/O, network I/O, IPC, etc). 
> Remember, if your registered process blocks, then the entire system will wait 
> for it to unblock before allowing any further access events. This has the 
> effect of a system "lockup".

I am doing this, but I actually am unclear on the effect the groupname 
has.  Suppose I have a bunch of threads monitoring the same directories, 
and they are all with the same groupname.  Now suppose you have another 
group doing the same thing on a different set of directories, but those 
all have different groupnames from each other (naive programmer set the 
groupname to be the threadid of the thread or something).  How will the 
two situations differ?

> If your application is only logging/monitoring events and never tries to 
> block events, then you should register your application in read-only mode:
>
> dazukoRegister("mygroup", "r");
>
> This reduces the number of kernel/user context switches by 50% and can also 
> have some benefits of reducing dead-lock risks.

It's actually read/write (it can deny access).  I didn't know that 
read-only is faster and saves context switches!!  I'll keep it in 
mind for my future Evil needs.  Thanks very much for your advice!!  :)


-Calin