dazuko-devel
[Top][All Lists]
Advanced

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

[Dazuko-devel] 2.1.0-pre3 posted


From: John Ogness
Subject: [Dazuko-devel] 2.1.0-pre3 posted
Date: Fri, 25 Mar 2005 00:51:39 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20050313)

Hi,

I have finally posted 2.1.0-pre3. The new trusted application framework is included. You can read about how it works in the README.trusted file. I am really curious to get some feedback about this fairly major new feature.

This version also includes a new dazukoInitializeCache() function, which can be used to activate kernel-level access caching. This can dramatically reduce overhead because the kernel will only report file acceses for files that have changed since the last reported event. Currently this function only has meaning for RSBAC systems. This function will always return error for non-RSBAC systems.

Aside from many small clean-ups and re-organization in the code, this version also solves the "flush on close" problem. Up until now, registered applications would often not see the final bytes written to a file when it is closed. This is because the registered application was receiving the close event and reading the file before the kernel actually had a chance to flush the data. This problem was originally pointed out by Petter Wahlman quite some time ago. The problem has been solved by treating CLOSE events as read-only. Since a close was never "blockable" anyway, there is no functional penalty for this. This means that the kernel actually completes the full close() process (flush included) before the registered application receives the close event.

Right now Dazuko uses PID for process identification. I would like to move to something more reliable (such as pointer addresses and/or process attributes). I would like to do this before releasing 2.1.0. Other than that, I feel that the current 2.1.0-pre3 is ready. But I am anxious to get some feedback about TAF (trusted application framework). This is a feature that has been heavily requested by the developers of Dazuko-based applications. I want to make sure that it's been implemented in a way that will make everyone happy (if such a thing is possible).

John Ogness

--
Dazuko Maintainer




reply via email to

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