what's in the works

[Timothy R. Chavez]

On Monday 28 March 2005 11:05 am, Timothy R. Chavez wrote:
> 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.
>

3.  DELETE ALL WATCHES

This is something I was asked about last week because it'd be useful for the 
test team.  This should be relatively trivial to implement as a global linked 
list to all the watches.  I don't care about their locations in the 
filesystem, just that I can unlink them from their watchlists and put back 
all references so that they can be properly freed.  This will come later, 
after the next patch is out, because I really do need to get this... 
<exhibits self-control>... "darn thing", out.
 
-tim