two sets of fs_watch/fs_inode messages?

[Timothy R. Chavez]

On Wednesday 10 August 2005 16:50, Timothy R. Chavez wrote:
> On Wednesday 10 August 2005 15:14, Linda Knippers wrote:
> > 
> > >>I'm running the sample CAPP rules with the .87 kernel and 1.0.1
> > >>audit tools.  I'm seeing duplicate watch/inode messages sometimes.
> > > 
> > > Did this happen in previous kernels? .85 or .80 for example.
> > 
> > I just tried .77 and .81 (what I had handy on my system) and it does the
> > same on both of those.
> Hi,
> 
> I haven't been able to spend any time on this issue, but I don't necessarily 
> consider it a critical issue or anything that needs immediate attention.  
With
> the new fswatch framework and auditfs piece the first half of this problem 
is
> addressed and the second half does not [yet] exist.
> 
> What needs to happen and does happen in the new framework is that the
> aux linked-list on the audit_context is walked and checked for the FS_INODE.
> If it exists, the watch is added to that FS_INODE, otherwise a new FS_INODE
> on the aux list and the watch is added to it.  This effectively consolidates 
> all watches to one corresponding FS_INODE entry.  
> 
> Now, the second half of the problem, reporting identical FS_WATCHes is non-
> existant in the new audit framework currently due to the "fsnotify"-like 
> hooks. 

I should definately correct myself... When I wrote "new audit framework" I 
really meant the  "new 'watchfs' framework".  And my apologies on the weird 
pseudo run-on sentence :) *cough*

-tim

> What we're seeing now is the same hook being hit multiple times in  
> the same code path because this system was designed around hook 
> consolidation.  This might become a problem if we add an "fsnotify"-like 
hook 
> to critical functions like permission() which might be called multiple times 
> in the same code path (hooking this function might not even be needed 
> though).  In the event that we do introduce the possibility of duplication, 
> the record should probably be discarded.  This could be kind of expensive 
> having to first walk the aux list and then walk the FS_INODE's watch list 
> comparing fields.
> 
> -tim
> 
> 
> 
> > 
> > -- ljk
> > 
> > --
> > Linux-audit mailing list
> > Linux-audit at redhat.com
> > http://www.redhat.com/mailman/listinfo/linux-audit
> > 
> > 
> 
> --
> Linux-audit mailing list
> Linux-audit at redhat.com
> http://www.redhat.com/mailman/listinfo/linux-audit
> 
>