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

[Stephen Smalley]

On Fri, 2005-03-25 at 10:46 -0600, Timothy R. Chavez wrote:
> I've kind of struggled with this one and am was a bit reluctant to add it.  
> Perhaps my logic is right, bu there's a better placement.  The reason why the 
> hook was placed in __d_lookup() was to auto-update a hardlink with the 
> correct watch.  The only way a hardlink will generate audit records is if 
> it's inode is being watched and the only way the inode can be watched is if 
> one of it's dentry's is at a watch point.  So, take this scenario for example 
> -- this is how we should currently perform:
> 
> watch /tmp/foo
> # We get a record for "foo"
> cat /tmp/foo

So at this point, the inode has hit an audit_attach_watch() upon the
d_splice_alias() call during lookup and is marked as requiring audit,
right?

> ln /tmp/foo /tmp/bar

Same inode, so it is still marked as requiring audit (but you need an
audit_notify_watch call at the tail of vfs_link to generate one for the
link creation).

> watch /tmp/bar

Why?  We aren't trying to defend against stupid or malicious admins
here.

> # We get a record for "foo"
> cat /tmp/bar
> rm /tmp/foo
> # __d_lookup() does its magic and we get a record for "bar"
> cat /tmp/bar

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?

-- 
Stephen Smalley <sds at tycho.nsa.gov>
National Security Agency