Re: [RFC][PATCH] filesystem auditing by location+name

[Christoph Hellwig <hch@infradead.org>]

On Sat, Jun 11, 2005 at 11:55:11AM -0500, Timothy R. Chavez wrote:
> 1) Coverage
> 
> Inotify is only interested in a portion of the fs ops that we are interested 
> in.  Most notably, we need the ability to generate records every time the 
> [exec_]permission[_lite]() function is called.

That still means you could use the same infrastructure and now forward
these events to inotify-ish clients, right?

> 2) Processing
> 
> The processing of events has to occur in the kernel, not in user space.  
> Inotify collects events and tosses them back over the fence for processing.  
> We cannot introduce any window of opportunity for audit subversion.

still means it could be a client to the same core event processing code
and filesystem hooks, right?

> 
> You see, auditfs is interested in the inode at location+name, whatever it may 
> be when the auditable event occurs.  Thus, we've had to hook dcache to help 
> us with this processing.  This is something Inotify does not care about nor 
> should it.

Nor should the auditing code.  There's no way to find a good name for an
inode _at all_, and only the last pathname component for a dentry.  If you
try anything else your code is broken and will not get anywhere the mainline
kernel.

> 3) Queue
> 
> Depending on the work, there may be a requirement that no audit record can be 
> lost.  The message queue structure of inotify has the potential to overflow 
> and drop events.  This is a no-go for us, but perfectly reasonable for 
> inotify.
> 
> To make this work for us we'd have to hook the queueing functions to forward 
> events on to the audit subsystem.  This would basically mean fitting a system 
> that has been designed for interaction with userspace to also have 
> interaction with other parts of the kernel... again, hackish.

Or build inotify ontop of your system.  It's not like inotify is perfect
as-is (it's not, the userland interface is extremly horrible)