Messages in this thread | | | Date | Sat, 11 Jun 2005 18:00:22 +0100 | From | Christoph Hellwig <> | Subject | Re: [RFC][PATCH] filesystem auditing by location+name |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |