[RFC][PATCH] (#5) prelim auditfs

[Timothy R. Chavez]

Hello,

Before we get started I just have to tell the world:  It's a beautiful
day here in Austin, TX.

There were enough changes for this patch that I felt it'd be OK and
simpler if I just called it patch #5.  In this patch I fix the logic
which was pretty broken last time (man was it broken).  I also cleaned
up the code: reduced more code redundancy, tightened up helper
functions, fixed minor and major bugs, and attempted to make the code
more readable.

Two improvements:

1.

I did something which might be kind of ballsy, but it seems to work just fine.  

In a very tired state I tried explaining this one over the phone.  My
guess is that it made little to no sense -- sorry :( perhaps I'll be a
little more eloquent via e-mail.

A file/directory that is already being watched gives that watch
precedence on that inode.  This means that if we move a watched file,
/tmp/foo, to /tmp/bar and then watch /tmp/bar, /tmp/bar will still
report watch information for /tmp/foo (Likewise, if we moved /tmp/foo
to /tmp/bar and a watch already exists on /tmp/bar, the watch for
/tmp/foo would remain).  This is only semi-cool.  To become fully-cool
we'd also like to be able to adopt (automatically) the watch on
/tmp/bar if and when the watch on /tmp/foo is ever removed.  Hooking
d_lookup seemed like the best place to do this.

2.

There are three kinds of inodes that make use of the audit_data inode
struct: watched, watching, both.  When we watch an inode that is also
watching, it'd be a mistake to overwrite it with the preallocated
memory associated with that watch entry.  There goes the watchlist,
doh!  So, in this case, we simply transfer into the preallocated
memory the inode's current audit_data.  This has a nifty side-effect. 
Iff the inode is stationary in the filesystem (movement destroys
watchlists), then if we were to delete and recreate the directory, its
watches would still be intact.  If we remove the acutally watch, the
watchlist will automatically be drained.  To remove individual
watches, the directory would have to first be resurrected.

What is left?

- Feature:  List all watches currently in the filesystem
- Comments:  Add [better | more] comments
- Test, test, test

Testing:

Starting tomorrow, Loulwa S. will officially be joining this project,
and will be helping me with the functional test case development
needed for the auditfs piece.

Chris, I wasn't really able to find much on the umount() problem the
Inotify guys were having.  I found a conversation / beat down which
alluded to it, but that's it.  Still, I hadn't actually tested the
behavior when I umount a device that has watches on it, so I figured
I'd at least do this test:

I added watches to a mount, removed the mount, and saw all the watches
putting back all their references and being freed / put back into
their respective caches.  This is the correct behavior in my book. 
Was it something more / different?

Still unable to provide userspace piece for testing.  I am going to
port it to audit-0.6.4

Please, please, please... look this over and give comments, feedback,
and suggestions.  Don't hold back, let me have it.

-- 
- Timothy R. Chavez
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linux-2.6.10-auditfs-tc1-5.patch
Type: text/x-patch
Size: 33389 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20050228/2cb9299a/attachment.bin>