[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dazuko-devel] DazukoFS for FreeBSD 6 (early preview)

From: John Ogness
Subject: [Dazuko-devel] DazukoFS for FreeBSD 6 (early preview)
Date: Mon, 20 Feb 2006 23:17:21 +0100
User-agent: Debian Thunderbird 1.0.2 (X11/20051010)


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:


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

$ env CVS_RSH=ssh cvs -z3 \
-d:pserver:address@hidden:/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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]