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

[Christopher Chandler]

Hi Dazuku-Help,

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. Here's what I've tried.

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.

2) I used CVS to provide a source tree using cvs -d:pserver:address@hidden:/sources/dazuko co . Using this distribution (the latest and greatest source) 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:

/**
 * __d_path - return the path of a dentry
 * @dentry: dentry to report
 * @vfsmnt: vfsmnt to which the dentry belongs
 * @root: root dentry
 * @rootmnt: vfsmnt to which the root dentry belongs
 * @buffer: buffer to return value in
 * @buflen: buffer length
 * @fail_deleted: what to return for deleted files
 *
 * Convert a dentry into an ASCII path name. If the entry has been deleted,
 * then if @fail_deleted is true, ERR_PTR(-ENOENT) is returned. Otherwise,
 * the string " (deleted)" is appended. Note that this is ambiguous.
 *
 * If @dentry is not connected to @root, the path returned will be relative
 * (i.e., it will not start with a slash).
 *
 * Returns the buffer or an error code.
 */
char *__d_path(struct dentry *dentry, struct vfsmount *vfsmnt,
      struct dentry *root, struct vfsmount *rootmnt,
      char *buffer, int buflen, int fail_deleted)

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:

checking host system type... Linux
checking for make utility... ok (make)
checking for C compiler... ok (cc)
kernel source in /lib/modules/2.6.22.18-0.2-default/source... yes
kernel build source in /lib/modules/2.6.22.18-0.2-default/build... yes
acquiring Linux kernel code configuration... ok
checking if Linux is RSBAC patched... no
checking if devfs is enabled... no
discovered host system... Linux (2.6.22)
checking whether __d_path() is exported... yes
checking for System.map file... ok (/boot/System.map-2.6.22.18-0.2-default)
locating sys_call_table... ok (0xc02ce2a0)
checking sys_call_table status... read-only

IMPORTANT NOTE:
If you get a kernel panic or segmentation fault while loading
the Dazuko module, you will need to reboot and try to
configure Dazuko again with the --sct-readonly option.

locating do_execve... ok (0xc0175850)
identifying device API... ok
inspecting class type... ok (class)
inspecting suspend function... ok (suspend2)
inspecting task_struct structure... ok (using parent)
configure: creating Makefile
configure: creating library/Makefile
configure: creating example_c/Makefile

./configure successful

=======================
 Configuration summary
=======================

module events = ON_OPEN ON_CLOSE ON_EXEC ON_UNLINK ON_RMDIR ON_CLOSE_MODIFIED
devfs support = no
rsbac support = no
hooking via syscalls = yes
local __d_path() = no
path resolution = registered daemon context
module debug = yes
library 1.x compatibility = yes

and testing for __d_path:

grep __d_path /proc/kallsyms
c017f300 T __d_path

but

make -C /lib/modules/2.6.22.18-0.2-default/build SUBDIRS="/home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko" modules
make[1]: Entering directory `/usr/src/linux-2.6.22.18-0.2-obj/i386/default'
make -C ../../../linux-2.6.22.18-0.2 O=../linux-2.6.22.18-0.2-obj/i386/default modules
  CC [M]  /home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko_core.o
  CC [M]  /home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko_transport.o
  CC [M]  /home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko_linux.o
/home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko_linux.c: In function ‘xp_print’:
include2/asm/string.h:238: warning: array subscript is above array bounds
  LD [M]  /home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko.o
  Building modules, stage 2.
make[4]: Warning: File `/home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko.o' has modification time 0.33 s in the future
  MODPOST 1 modules
WARNING: "__d_path" [/home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko.ko] undefined!
  CC      /home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko.mod.o
  LD [M]  /home/chrisc/src/UNIX-Multi-Platform/BoxOS/src-external/dazuko/dazuko/dazuko.ko
make[4]: warning:  Clock skew detected.  Your build may be incomplete.
make[1]: Leaving directory `/usr/src/linux-2.6.22.18-0.2-obj/i386/default'
touch dummy_rule


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


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)

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

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.

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, 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? 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. In the mean time, is there a recommended approach for cancelling a dazukoGetAccess_TS() operation, EG: after a signal?

Following the example C program, I explicitly exclude /dev/ from the dazuko driver's search list. My test has been including /tmp/test/ so it should not have been interfering anyway.

I have tried running my test program as root and as an ordinary user (after chmod 666 /dev/dazuko) but that didn't seem to make any difference either

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? I haven't tried RSBAC (I really don't need the security stuff - in fact I want an ordinary user's process to be able to open /dev/dazuko in notification mode). I'm running Linux in a Virtual Machine (actually on Parallels Desktop for the Mac) so if you tell me that using another Linux distribution is the best bet, I can probably cope with that, but I'd rather not have to dump Suse if possible.

Any suggestions would be greatly appreciated!

Regards,
Chris