Messages in this thread | | | Date | Fri, 10 Dec 2004 04:38:05 +0000 | From | Timothy Chavez <> | Subject | Re: [audit] Upstream solution for auditing file system objects |
| |
On Thu, 09 Dec 2004 22:42:18 -0500, Robert Love <rml@novell.com> wrote: > On Fri, 2004-12-10 at 02:50 +0000, Timothy Chavez wrote: > > Hi, Timothy. You work for IBM? >
Yep.
> > > > Some way for inotify to "notify" other parts of the kernel of file > > system activity would be good. This is the arguement I'd like to use. > > If inotify can notify userspace apps of activity/events, why can't it > > notify kernel subsystems? There might be a very good reason as to why > > this can't be so. "Just because" might be it :-) Whatever the reason, > > it'd be good to hear. I wouldn't want to destroy or degrade the > > intended use of inotify, but expand it. If that's not doable, then > > there's no way we can use inotify. This would have to be something > > John and Rob and whoever else contributes to Inotify would like in > > addition to the community as a whole. > > I do not think it makes any sense for inotify to be the mechanism that > implements auditing. What you want is a general file event mechanism at > the level and time that we currently do the inotify hooks. I agree, > that is good. What you also want is to do is hack into inotify your > auditing code. I don't like that--I don't want inotify to grow into a > generic file system tap.
Fair enough. I agree that having something more generic at the hook level would be ideal. I'm interested in what others might think about this.
> What we both need, ultimately, is a generic file change notification > system. This way inotify, dnotify, your audit thing, and whatever else > can hook into the filesystem as desired.
> Subverting the inotify project to add this functionality now will only > hurt inotify. We are not yet in the kernel and we need to streamline > and simplify ourselves, not bloat and featurize. Besides, indeed, we > are not in the kernel yet--you can just as easily add the hooks > yourself.
Right, but we like inotify and want to see it succeed :-)! We also want an upstream solution, so playing nicely is essential.
> So my position would be that I am all for moving the inotify hooks to > generic file change hooks, but that needs to be done either once inotify > is in the kernel proper or as a separate project. Then inotify can be > one consumer of the hooks and auditing another.
It's a reasonable compromise and it'll have to be considered and discussed.
> If you want to move forward with a project to hook file system events, > go for it. Regardless, I think that you should post to lkml your > intentions.
Most definately. Thanks for the reply.
> Best, > > Robert Love > >
-- - Timothy R. Chavez - 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/
| |