Re: [audit] Upstream solution for auditing file system objects

From: John McCutchan
Date: Fri Dec 10 2004 - 00:23:55 EST


On Thu, 2004-12-09 at 22:42 -0500, Robert Love wrote:
> On Fri, 2004-12-10 at 02:50 +0000, Timothy Chavez wrote:
>
> 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.
>
> 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.

Yes, hopefully we can use some inotify bits when it comes time to do it.

>
> 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.
>
> 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.

I am in complete agreement here. Inotify was not designed with any of
this in mind. Inotify was designed with the desktop in mind. I think a
more realistic approach would be to get inotify in, then refactor from
there. Creating a generic layer that contains some of the inotify code
plus whatever is needed to implement this audit stuff. Then the audit
system and inotify could use this layer for the nitty gritty.

--
John McCutchan <ttb@xxxxxxxxxxxxxxxx>
-
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/