what's in the works

Hello, 1. LIST WATCHES I'm just finishing up the "list watches" feature and I have a question. With the current design, there is no way to tell the kernel, "give me a list of all watches". Currently, a watch is a structure with these fields: name : the name of dentry->d_name that's to be watched filterkey : an arbitrary string no greater then 32 bytes (including terminating \0) perms : permissions filter Thus you really wouldn't know the location of these watches. So, perhaps I could add a 'path' field which just kept the path I specified when the watch was inserted. But, this too might be misleading (if we are to every change namespaces) or the administrator uses a relative path. We technically do support relative paths when inserting/removing a watch (even though auditctl warns otherwise). Furthermore, would this look bad when trying to sell this to fsdevel or LKML? So, the compromise I came up with is to add an option to auditctl, '-L' which would allow the admin to check the watches on a given path. I think this fits decently with the idea behind this feature: to help the administrator remember what watches they set. So now, it looks like this: ./auditctl -w /audit/foo ./auditctl -w /audit/bar ./auditctl -L /audit AUDIT_WATCH : LIST : /audit/foo AUDIT_WATCH : LIST : /audit/bar I'm working on getting the entire struct exported to userspace so we can also say something about the perms filter and filterkey. 2. HOOKS So I've been experimenting around and have hooks capturing what I think is required by CAPP. Klaus, when this patch is released we REALLY need your input and appraisal. One of the problems we face here is that "access" can generate multiple records and for some reason it feels like the administrator would have to have some sort of knowledge of what's going on in the kernel that extends past intuition. For this reason, I feel like perhaps I should have another field that provides some sort of context to the record. So for instance, if the record was generated from a permissions function, we'd set the "context" field to show that. Is this a good idea? When I post the patch, I'll post it with a list of hooks and what each does. -tim