Re: [RFC][PATCH] (#6 U1) the latest incarnation
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