[Dazuko-devel] 2.0.3-pre4 posted

[John Ogness]

Hi,

I have posted 2.0.3-pre4. I expect this to be the final pre-release 
before 2.0.3. Some minor optimizations and bugfixes have been made to 
address a few reported problems.

There is one major change in this new version. Dazuko will no longer 
require "root" access. This means that anyone who is allowed read/write 
access to /dev/dazuko will also be able to perform file access control. 
Since the Dazuko HOWTO has said from the beginning that /dev/dazuko 
should be owned by root with permissions 600, I think this will cause no 
problems. However, it introduces the ability for a user to have non-root 
processes perform file access control or file access logging (for 
example, processes belonging to a dazuko group). Until now Dazuko 
required the Real UID to be 0 (rather than the Effective UID). This 
means that setuid processes will now also be able to access Dazuko. I am 
anxious to hear feedback on this change, but I feel that it is a 
positive change.

I worked all of last weekend on using the FiST framework to develop 
DazukoFS. I was successful. I have been able to develop a stackable 
filesystem (called DazukoFS) that is based on Dazuko. How does this 
work? DazukoFS is a transparent filesystem that is mounted on top of 
existing file systems. The file systems can be accessed just as before 
with the only difference being that Dazuko can control or log the file 
access events.

Advantages
- kernelspace NFS servers are supported
- based on FiST (building on the experience of another project)
- no system call table hooking (something that makes the kernel 
developers happy)

Disadvantages
- more complicated
- based on FiST (not yet considered production stable)
- file systems mounted later on will not be seen (such as /mnt/cdrom or 
/mnt/floppy)

DazukoFS will not be available until Dazuko 3.0 (planned for Feb 2005). 
For the 3.0 version I want to offer various options:
- DazukoFS (stackable file system)
- system table hooking hooking (as it is now)
- LSM (Linux 2.6) - hopefully with the "stacker" module

The user will have the option of choosing which should be used. I will 
also be focusing more on the "installation" of Dazuko. Right now much is 
spoken about compiling but nothing is spoken about installation.

Developers can take comfort in knowing that all these future changes 
have nothing to do with the Dazuko interface. This means that *how* 
Dazuko is installed and captures events is completely independent from 
the interface.

John Ogness

--
Dazuko Maintainer