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

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