Re: [PATCH 1/7] audit: convert audit watches to use fsnotify instead of inotify
On Tue, 2009-06-16 at 13:09 -0300, Klaus Heinrich Kiwi wrote:
On Tue, 2009-06-16 at 11:43 -0400, Eric Paris wrote:
> Note that audit watches don't use inotify to do any of the actual
> auditing. They just use inotify to discover the watched files were
> created or removed. So we weren't using much of the inotify feature
> set.
Eric,
thanks for the thorough explanation.
It's been a while since I last looked, but the file watches are being
audited at the syscall level, right? So inotify/fsnotify is used to
associate a filename to an inode when the file is created, or to
deassociate when it is removed. Is the rename/mv also covered by those
or differently? I remember that moving a file around doesn't invalidate
it's rule (the file's inode is still the same), but auditctl -l doesn't
follow the name around, for example.
But that's also probably the right thing to do in that case, I'm not
sure.
So fsnotify and inotify are the same in these regards. Basically a
watch is really on a "directory inode + a name" it's easiest to explain
what goes on in examples.
-F path=/tmp/dir1/file1 so the inotify/fsnotify watch is attached to
the /tmp/dir1 inode. We also maintain that what we care about is
"file1"
If you mv /tmp/dir1 to /tmp/dir2 the rule is deleted from the system
(and an audit config change record is written in the logs)
If instead you create /tmp/dir1/file1 we get a notification, update the
lists with the new inode number for /tmp/dir1/file1 and at syscall exit
will output a record if the /tmp/dir1/file1 was accessed.
If you delete /tmp/dir1/file1 or move it to /tmp/dir1/file2 we will
update the lists with the fact that there is no inode
for /tmp/dir1/file1 and so when a syscall exits it will not obviously
not find that it needs to output a record.
So we handle add/remove/mv of the actual file of a watch as would be
expected. If the file this syscall accessed was called [blah] at
syscall exit we will emit a watch. If the file wasn't called [blah] we
won't. The only thing interested is removing or moving the parent
directory, which actually removes the whole rule never to return.
-Eric