Hi, I have now committed the current DazukoFS work for FreeBSD 6 into CVS. For FreeBSD 6, DazukoFS is based on nullfs. Although nullfs is not officially supported by the FreeBSD project, it works well enough to do a lot of testing.
I am posting this information for FreeBSD 6 users who are interested in seeing how DazukoFS will work. This should only be used for test purposes and only on machines (real or virtual) where total filesystem corruption or other disasterous effects are acceptable. (For example, I have done all of my development and tests in qemu or VMWare virtual machines). I have not experienced any problems with DazukoFS during my last few test sets, but users should be aware of the risks. Once Dazuko has been compiled and loaded into FreeBSD 6, you can use the mount_dazukofs utility to stack DazukoFS on top of an existing mount. The stacked dazukofs must have a different mount point. (This will change for the future, but for now they must be different.) As an example, typically /usr is a mount point for FreeBSD 6. Rather than mounting the partition to /usr, we could mount it to /usr.real (for example). Then we could stack DazukoFS on top of it using: # mount_dazukofs /usr.real /usr Now you can see all the files from /usr.real within the /usr mount. Any files accessed in /usr can be detected by Dazuko (and blocked). When running the example program, you can see all the accesses taking place: # ./example / (Although "/" is used, only access events for the particular mount will be detected.) Unlike previous versions, Dazuko no longer provides the real names of the files being accessed. Instead, pseudo-names are used. These look something like this: /usr/=dazukofs.0 Although these filenames do not actually exist, your registered application may open this file and will indeed receive a file descriptor to the real file. There are 3 major advantages to not using the file's real name: 1. Some files may not have a name, thus making them unaccessable for other processes by filename. 2. Looking up filenames is very expensive, so avoiding the lookup saves a lot of cycles. 3. We don't have to worry about chroot situations because we aren't interested in the root. However, I am aware that some applications would like to have the real name of the file. We will be introducing a new DazukoIO function (which could be called between dazukoGetAcccess() and dazukoReturnAccess()) to retrieve the filename if possible. This will allow application developers to decide when they want to invoke the expensive (and sometimes unreliable) lookups. Using DazukoFS it should be no problem capturing events on any filesystems (including kernel mode NFS servers). When you are finished doing testing, you simply unmount DazukoFS first, then you can unload the kernel module. # umount /usr # kldunload dazuko (Don't forget to unmount/mount your /usr partition back to /usr.) Some things to be aware of: - Only the registered application that received the event (or one of the trusted applications) can access the pseudo file. This prevents unwelcome applications from snooping. - At the moment only OPEN events will be generated. This is sufficient to do testing. It should not be a problem to add the other events later. - It is not yet clear what all the effects of calling rename(2) on the pseudo files are. - This has only been tested when stacking on UFS2 filesystems and IDE devices. It is not known how other filesystems or other devices types will react. If you interested in doing testing for FreeBSD 6, you can get the source with: $ env CVS_RSH=ssh cvs -z3 \ -d:pserver:[EMAIL PROTECTED]:/sources/dazuko \ co -r REL_3 dazuko Then run the setup script within the dazuko directory: $ ./setup_dazukofs_freebsd6.sh This will create the DazukoFS source code using the nullfs code as a model. Only FreeBSD 6 is available right now. NetBSD 2.0.2 and Linux 2.6 are next on the list. (We already have working examples, but it takes time to get the development/debug stuff cleaned up for the public CVS.) John Ogness -- Dazuko Maintainer _______________________________________________ Dazuko-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/dazuko-devel
