[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]