Re: [Dazuko-help] All Dazuko events with, OpenSuse 10.3 and latest patches from OpenSuse, Kernel 2.6.22.18-0.2-default

[John Ogness]

Hi,

I'm answering this email even though you've (appropriately) decided to
use inotify instead.

On 2008-07-30, Christopher Chandler <address@hidden> wrote:
> I've been trying to use the Dazuko driver as a mechanism to detect
> file-system events in the Linux kernel. Unfortunately, I'm having a
> certain amount of grief getting events other than ON_OPEN and
> ON_CLOSE. I saw the FAQ that suggested I should use the syscall
> mechanism.

Correct. ON_CLOSE events are only available when using the syscall
hooking method. The upcoming DazukoFS will also support this event
once it is further developed.

> 1) The dazuko package provided with Open Suse 10.3 seems to use the
> LSM mechanism, and so only detects ON_OPEN and ON_EXEC. It works,
> but isn't very useful for my purposes. ON_OPEN is useful, but
> ON_CLOSE_MODIFIED is much more useful to me, as would be other
> events that indicate changes in a file system.

ON_CLOSE_MODIFIED is currently not implemented in Dazuko. This is
something that is quite difficult to do from the kernel's perspective
and rather simple from a userspace application's perspective. The
application should implement this. The Dazuko documentation should be
updated to mention this.

> 2) I used CVS to provide a source tree ... I tried to build the
> kernel driver using the syscall interface. There are some problems
> with this.
>
> _d_path() appears to have one more argument than the dazuko source
> expects. Looking at /usr/src/linux-2.6.22.18-0.2/fs/dcache.c, around
> line 1763, it appears that __d_path()'s implementation has the
> following...
> 
> I tried modifying the dazuko source to provide the extra actual
> parameter 0 for fail_deleted. When I did this, the driver compiled
> but would not link saying that __d_path() was not exported despite
> the configure script thinking that it was.

Unfortunately the export status of the System.map is not reliable. You
would need to modify your kernel sources to export this function. (A
patch for this is included in the Dazuko distribution package.)

> I'm not a Linux kernel expert, but it was my understanding that a
> capital "T" meant that the symbol has been exported.

Normally, yes.

> 3) In the interests of trying to make something work, I tried the
> --disable-chroot-support option which allowed the module to be
> built. The driver was successfully installed, but I can only get
> ON_CLOSE events even though I've requested all of them (access mask
> is 31)

Hmmm. You should be able to get ON_OPEN and ON_EXEC as
well. Additional events can be activated with configure options. (See
"./configure --help" for all available options.)

As mentioned before, ON_CLOSE_MODIFIED is no longer implemented in
Dazuko.

> 4) When I tried again using --sct-readonly, it didn't seem to change
> much

This option only exists to work around a problem of the System.map not
showing the true export status of symbols. The option is only
necessary if the kernel crashes as soon as Dazuko is
loaded. Otherwise, it has no effect.

> 5) I also tried using the 2.3.5 dazuko distribution for Linux
> kernels 2.2.0 to 2.6.22 from the download page but got similar
> results.

There is not much difference between 2.3.5 and the CVS version right
now. Most Dazuko development is being directed towards DazukoFS.

> I've also noticed that the whole thing makes the Linux environment
> very fragile, whether using the LSM or syscall methods. Interrupting
> a program that has opened /dev/dazuko seems to make everything
> deadlock,

As mentioned in the Writing Apps HOWTO, a registered application has a
great deal of responsibility. If a registered application does not
unregister, Dazuko will not be made aware of its departure and
patiently wait for the application to request an access event. If the
registered application set the include path to something like "/" then
this causes the system to idly hang.

> even though I'm registering for "r" access - notification only - so
> I rather expected that this would not serialise file-system
> operations as there's no need to wait for the decision to deny the
> operation or not. Is what I'm seeing "correct" behaviour?

This is the correct behavior. When registering for "r" access, Dazuko
does not wait for the application to "return" the access. However,
when the _next_ access event comes, Dazuko will patiently wait for the
registered application to request an access event.

Dazuko is primarily a "file access control" mechanism and not a
"notification" mechanism. This requires that file access is not
granted until a registered application has allowed that access. (Or in
the case of the "r" mode, until the registered application has at
least been informed of the event.)

> If so, may I respectufully suggest that it should not be!  In my
> Windows and OS X drivers that do similar things to dazuko, I do not
> block the kernels when notifying. Instead, I queue up the events and
> dump them if I reach a maximum queue length.

As you later discovered, inotify is what you want. inotify is an
excellent solution for "relaxed" notification, where file access
control is not an issue.

> In the mean time, is there a recommended approach for cancelling a
> dazukoGetAccess_TS() operation, EG: after a signal?

Sending a signal to the thread should cause it to abort from the
dazukoGetAccess_TS() blocking. Then you can unregister using
dazukoUnregister_TS(). The example_mt program included in the Dazuko
distribution package does this.

> What I'm really asking is advice on how best to get all the events
> from the dazuko driver, not just either ON_CLOSE or ON_OPEN on my
> kernel? Which source tree is the best bet? Which options are known
> to work? Must I use a newer Linux kernel?

Currently the best supported method of using Dazuko is to use a 2.6.25
kernel with LSM. However, this will only give you ON_OPEN and ON_EXEC
events.

John Ogness

-- 
Dazuko Maintainer