Re: [PATCH] audit: file system auditing based on location and name

[Greg KH <greg@kroah.com>]

On Wed, Jul 06, 2005 at 03:23:10PM -0500, Timothy R. Chavez wrote:
> This is similar to Inotify in that the audit subsystem watches for file
> system activity and collects information about inodes its interested 
> in, but this is where the similarities stop.  Despite the fact that the
> Inotify requirements only dictate a subset of the activity the audit
> subsystem is interested in, there is a more fundamental divergence 
> between the two projects.  Like audit, Inotify takes paths and resolves 
> them to a single inode.  But, unlike audit, Inotify does not find the path 
> itself interesting.

Huh?  inotify users find that path interesting, as they use it to act
apon.

> Much like the (device,inode)-based system call filters 
> currently available in the audit subsystem, Inotify targets only individual 
> inodes.  Thus, if the underlying inode associated with the file /etc/shadow 
> was changed, and /etc/shadow was being "watched", we'd lose auditability 
> on /etc/shadow across transactions.

That's why you watch /etc/ instead, which catches that rename.  That
being said, why would not inotify also want this functionality if you
think it is important?

> More so, Inotify cannot watch inodes that do not yet exist (because
> the file does not yet exist).  To do this, the audit subsystem must
> hook deeper than Inotify (in fs/dcache.c) to adapt with the file
> system as it changes.  Where it makes sense, the small set of
> notification hooks in the VFS that Inotify and audit could share
> should be consolidated.

As inotify works off of open file descriptors, yes, this is true.  But,
again, if you think this is really important, then why not just work
with inotify to provide that kind of support to it?

I suggest you work together with the inotify developers to hash out your
differences, as it sounds like you are duplicating a lot of the same
functionality.

Also, inotify handles the namespace issues of processes by working off
of a file descriptor.  How do you handle this?

Do you have any documetation or example userspace code that shows how to
use this auditfs interface you have created?

thanks,

greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/