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

[Timothy R. Chavez]

On Friday 25 March 2005 07:28 am, Stephen Smalley wrote:
> On Fri, 2005-03-25 at 08:04 -0500, Stephen Smalley wrote:
> > With regard to additional hook placement for audit_notify_watch, I think
> > you likely do want to mirror the security*_post* hooks for file creation
> > (create, mkdir, mknod, symlink), rename, and link with
> > audit_notify_watch calls to perform notifications of such events.  Then
> > you keep audit_attach_watch calls in the dcache routines to manage the
> > i_audit fields and avoid races.  However, I think you need to check
> > whether you truly need all of the current hook placements in the dcache
> > routines or whether some of them are duplicative on the same code path,
> > e.g. do you need both __d_lookup and d_instantiate/d_splice_alias
> > hooked?
>
> I don't see what the __d_lookup hook buys you, can you explain?  The
> d_instantiate and d_splice_alias hooks ensure that you attach watches to
> inodes when they are looked up or created before they can be accessed by
> another thread via the dcache (since you call the hook before releasing
> the dcache lock).  What do you need the __d_lookup hook for?

Hello,

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
ln /tmp/foo /tmp/bar
watch /tmp/bar
# 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

This might be a completely assanine case now....

If /tmp/bar has a "natural" watch (ie: there's a watch on /tmp for "bar"), 
and /tmp/bar is a hardlink to /tmp/foo, then if /tmp/foo left (it was the 
dentry for the inode that was fufilling the watch criteria), then the inode 
would lose its "foo" watch and /tmp/bar would be watchless.  But /tmp/bar is 
being watched!  So we use __d_lookup() to automatically detect whether or not 
there is a "natural" watch in its current path that it can attach too.  This 
could get a little more interesting if there are N hardlinks to /tmp/foo 
which are all being watched.  Then, any of the /tmp/XN's could claim the 
inode and attach their watch -- it depends on what /tmp/XN calls the 
audiit_attach_watch() first.

Comments? Opinions?

-tim