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

From: Christoph Hellwig
Date: Sat Jun 11 2005 - 12:03:07 EST


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)

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