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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
