[RFC][PATCH] (#4) auditfs

Hello, New patch. DONE: - Prelim userspace patch to audit-0.6.2 (I will port this to 0.6.3 soon) to compliment Patch #4 (unavailable for public release at this time). More work needs to be done in this area at a later date (cleanup, man page, etc). - Support for filtering out watches that are accessed in a way we do not care about during syscall execution (ie: we only want to receive audit records for /etc/passwd if we MAY_WRITE on it) - Support for enabling / disabling filesystem auditing from userspace (ie: auditctl) - Refined logic that asserts priority. In general, objects being watched will never be overwritten with a new watch. If the object is unwatched and another watch is available, it will take on that watch. - Added the notion of a "valid" and "invalid" watchlist entry. - More structure to the overall system * Refined core structs * Added more helper functions * Reduced redundant code - Put protections around user space input. - Correctly handle the filterkey field of the user space message * Also allows for sending the same struct back to userspace - Hooks in vfs_read/write/unlink (please look closely here). The rule of thumb I went off of is: I can call my hook iff I have an inode and I'm NOT hooking lookup_hash *nudge Stephen* :) - Cleanup of some of the public functions / macro pairs. - Some minor odds and ends WHAT'S LEFT: - Final feature to list all the current (valid) watches in the system - Fix bug introduced by new logic. We are not able to print all watched components in a path in a specific scenario due to the added logic. - Change wentry->w_watched to wentry->w_valid..... I found out the hard way that wentry->w_watch and wentry->w_watched are too similar :-) - Write prelim design document - Comment my code better - Fix any remaining Patch #4 bugs - Fix the inode bug in original code where the reported inode is incorrect for unlink()s (it's the parent's inode) - Oh and cleanup some more redundant code with watch removal from a watchlist I hope Patch #5 is quick (by the end of this week) and will be the one we bring to Al Viro next week? If you could please give this a quick look over and raise flags / issues / nits, I'd really really appreciate it. The positioning of my new hooks could be bad, please let me know. I'm on 3 hours of sleep. Three hooks for dynamically assigning watches: d_splice_alias, d_move, d_instantiate Five hooks for dynamically adding watches to our context: permission, exec_permission_lite, vfs_read, vfs_write, vfs_unlink I'm sending this to the internal list today to get some more eyes to review (I hope) -- - Timothy R. Chavez