what's in the works

[Timothy R. Chavez]

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