Hello, A few weeks ago I posted some mail stating my concern for the direction being taken to try to get audit's additional filesystem pieces upstream. I've done some research into other possible approaches and thought I'd post some thoughts. Audit Requirements ------------------ First, here is my understanding of how the upstream audit code must be augmented to meet CAPP requirements, which are the baseline requirements for audit. - Provide the capability to specify filters for non-existent files/directories, provided their parent directory exists. Filters must take effect when a file/directory is created at the specific location. - Provide persistence for filters specified with a given pathname, given the existence of the parent directory. Filters must be applied to all filesystem events happening at said pathname. - Provide additional filesystem information not captured by the getname() and path_lookup() hooks, e.g. inode information for created files. Suggested Approach ------------------ The plan proposed several weeks ago was to write a general filesystem event notification component for the kernel, based on the current auditfs patch. I think this is a mistake for several reasons. - The auditfs patch was not designed to be used by multiple clients. - The locking performance is relatively untested, and was not designed for multi-client use. - The auditfs patch was designed to meet the specific needs of audit and may not meet the needs of other consumers. We would need to go through some requirements discussions to ensure any consumers needs were met. - The desired functionality is essentially already there in Inotify. Inotify is designed to be used by multiple clients, has clean locking, and has undergone quite a bit of testing and performance work. It already does most of what audit needs. It provides the capability to watch a parent directory for file or link creations, renames, and removals. It also provides events for attribute changes. I believe audit's remaining requirements on Inotify are few. In order for audit to use Inotify, Inotify would need to provide: - An Inotify kernel API. - A pointer to the relevant inode struct when a filesystem event occurs. - The ability to begin watching a file at the moment of creation. Currently audit is pre-notified, via dcache hooks, when a file is created, moved, or deleted. This allows audit to enable or disable a watch on the appropriate inode. Audit would need a similar pre-notification, or preferably the ability to add (and possibly remove) watches from an Inotify event callback. - Possible changes to fsnotify hook placement to ensure that the information recorded by audit (inode, filename) is correct. - Possible additional filesystem events correlating with some of the events currently obtained from audit's catch-all hooks in permission() and exec_permission_lite(). In order for audit to use Inotify, audit would need to: - Create an Inotify watch on the inode of any existing file/directory specified in audit filters. - Create a corresponding Inotify watch on the parent directory of any file/directory specified in audit filters. This watch may only need to exist when the specified file/directory doesn't exist. - Provide an event callback which would perform the necessary actions for various filesystem events. This would involve updating the audit_context and adding (and possibly removing) Inotify watches. - When watched inodes go away, Inotify automatically removes any relevant watches and generates a removal event(s). Upon receiving the removal event, audit would log an 'implicit removal' record. Progress & Next Steps --------------------- A couple weeks ago I wrote a patch that provides a basic Inotify kernel API, as a proof of concept. I'm sending that patch in a follow-up email. I also sent it to John McCutchan (cc'd) for feedback. He has been supportive of the effort, but would like us to tighten audit's requirements so he can determine if the necessary changes would make sense for Inotify. I've also been working on understanding audit's specific needs regarding VFS hook placement. I would like to discuss this some more to determine whether this approach is indeed viable. John (and Robert), please let us know if you would like to be party to these converations, or if you would prefer we send you a summary. Other Things to Consider ------------------------ Any approach to getting the audit filesystem pieces upstream will require some changes to the current implementation. I think this would be a good opportunity to do some data structure consolidation. Filesystem data collected by the auditfs filesystem hooks is not integrated with other filesystem data collected during system call processing. Information collected from the getname() and path_lookup() hooks is stored in the audit_context's names[] list, and is logged as AUDIT_PATH records. Information collected by hooks in namei.c, attr.c, and xattr.c is stored in auxiliary audit_aux_data_watched structures and is logged as AUDIT_FS_INODE and AUDIT_FS_WATCH records. These pieces of information are never tied together other than by having the same audit record serial number. I don't see any reason why this needs to be the case. At the very least, combining these two parts of syscall processing would result in more readable audit records. Thanks for taking the time to read this email. I would appreciate any comments on both the Inotify approach and the data structure consolidation possibilities. Regards, Amy