[Top][All Lists]

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

[Dazuko-devel] 2.3.4-pre1 posted

From: John Ogness
Subject: [Dazuko-devel] 2.3.4-pre1 posted
Date: Mon, 27 Aug 2007 22:20:10 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (berkeley-unix)


Today I have posted 2.3.4-pre1 of Dazuko. Here is a brief description
of each of the new items:

- LSM 2.6.23
  Support for the upcoming Linux 2.6.23 LSM API has been added.

- new option "--sct-nocheck"
  A new configure option has been added to disable the syscall table
  checks. These are used when you are using syscall hooking with Linux
  2.6. On non-x86 architectures these checks do not work correctly
  (you cannot compile them). So for non-x86 architectures these checks
  can be disabled.

- removed __d_path() dependency (Linux 2.6 + LSM)
  For Linux 2.6 support using LSM, the dependency on __d_path() has
  been successfully removed. This means that SMP machines can safely
  detect chroot'd processes without requiring any special kernel
  patches. Note that this is only available for LSM. If you are using
  syscall hooking with Linux 2.6, the dependency will still exist.

  I was able to implement this feature by allowing the filename
  resolution to occur within the context of the registered process
  (rather than the context of the process accessing the file). This
  idea came about because this is how we plan to implement filename
  lookups with DazukoFS.

  It was not possible to implement this idea with syscall hooking
  because of the limited information available to Dazuko on for most
  system calls.

  Please be aware that although syscall hooking is available, LSM is
  still the default and recommended method for using Dazuko with Linux

It's been quite a long time since Dazuko's last release. This is due
to several factors:

- There has been a lot of proof-of-concept code being written in the
  background. This code may serve as a basis for the new DazukoFS as
  well as a completely new Dazuko core. Dazuko's code has grown
  unnecessarily complex over the last 5 years. (One coule argue that
  it was never very clean.) With the experience gained until now, we
  could write a much cleaner and more efficient core. Once I complete
  a prototype of the new core, I will introduce it in the next
  experimental 3.0 preview. I hope to also include cleaned up and
  improved DazukoFS support.

- I have been investigating several alternatives and talking to
  people. I have been doing research about writing file systems and
  (recently) began investigating FUSE seriously. Unfortunately, the
  more I learn, the more I see how much work this stackable filesystem
  will be. :-/

- A couple months ago I decided to change jobs. This introduced some
  political discussions about the Dazuko project and my role as its
  maintainer. Although not yet completely sorted out, I believe that
  the direction of the project is not at risk by this.

John Ogness

Dazuko Maintainer

reply via email to

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