Re: [RFC][PATCH] (#6 U1) the latest incarnation
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(a)tycho.nsa.gov>
National Security Agency