[RFC][PATCH] (#6 U1) the latest incarnation

[Timothy R. Chavez]

On Friday 25 March 2005 11:25 am, Stephen Smalley wrote:
<snip>
> Wait.  We are still dealing with the same inode at this point.  Why was
> its i_audit field changed by the delete if there are other hard links
> present?  Don't we want to preserve auditing on the inode in such a
> case, irrespective of whether /tmp/bar had a watch or not, just because
> of the original watch on /tmp/foo?

Just to be clear on this, I think the way I'm doing it now gives us the a 
fairly clear statement on what constitutes "being watched".  Iff a dentry 
exists such that dentry.d_name->name eq watchlist_entry.name, will the 
dentry->d_inode be able to hold a watch.  

Because dentry->d_inode is sharable, this allows for implicit watches at other 
locations in the filesystem.  The watch on a hardlink is not explicit.  The 
only reason we're watching the hardlink, /tmp/bar, is because it 
shares /tmp/foo's inode; /tmp/foo exists. Once /tmp/foo is gone, the watch 
point is vacated, and we're no longer interested in receiving audit records.  

If /tmp/foo comes back, /tmp/bar will not be watched... is this a shortcoming?  
I don't look at it like this.  I don't think we should make any assumptions 
of the kind (it makes things simpler :-)).  I think this scenario lumps into 
the same category as mounting over /tmp with a new device and then 
automatically watching /tmp/foo because we've specified this path.  
The /tmp/foo on this new device might be completely different (ie: it was 
targeted by the administrator for audit) and something we don't care about.  
When the administrator watches, he/she does so explicitly on a given device, 
in a given namespace.

Through all of this we can now say that a watch may only ever be attached to 
one inode and that inode must have a dentry associated with it who's name 
appears in its parent inode's watchlist.

I'm under the impression that this is acceptable for a CAPP evaluation.  
Klaus??
 
-tim