From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH 1/7] audit: convert audit watches to use fsnotify instead of inotify Date: Fri, 19 Jun 2009 17:03:50 -0400 Message-ID: <1245445430.19333.80.camel@dhcp235-23.rdu.redhat.com> References: <20090612203159.12332.42771.stgit@paris.rdu.redhat.com> <1245165908.4771.2.camel@klausk.localdomain> <1245167038.2848.25.camel@localhost.localdomain> <1245168590.4771.20.camel@klausk.localdomain> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1245168590.4771.20.camel@klausk.localdomain> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Klaus Heinrich Kiwi Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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