[RFC][PATCH] (#4) auditfs

[Chris Wright]

* Timothy R. Chavez (chavezt at gmail.com) wrote:
> Just a heads up.
> 
> I've come across several glaring bugs (such as creating a cache with
> the wrong struct sizing), a couple bugs in audit_watch(), etc.  I've
> also reduced redundant code and made some of my helper functions
> tighter.  I'll be releasing an intermediary patch that has all these
> changes, including the elimination of whitespaces and other bogus
> information in the patch.  I hope this patch will pretty much be patch
> #5 without the remaining feature to list all the watch points
> currently in the FS.
> 
> On a similar note,
> 
> I'd like to start getting feedback on linux-fsdevel with a CC directly
> to Al Viro about the design itself.  What do you all think of this
> approach?  Or perhaps I should bring it directly to LKML?  Should I
> wait until the intermediary patch #5 is completed and tested before I
> start any dialog?  I personally think overlapping the two would be
> fine.  The reason I think this is because the first major stumbling
> block has nothing to do with the implementation itself, but the design
> and all the philosophy and politics surrounding it.  As soon as I
> mention "filesystem auditing" I've noticed that people get antsy and
> immediately try to beat it down like a pianta made out of software
> patents J/K.  Thus I feel a large part of this endeveour is going to
> revolve around explanation.  Do you agree?  I'd appreciate some
> feedback.

I'd not submit something with known glaring issues, so whether it's
the fixed #4 (intermdiary or whatever), or #5, at least make sure it's
as clean as possible.  I'd also make sure that locking is correct, and
that you've cared for refcounting things properly in the case of umount,
for example (IOW, look out for the things that inotify got wrong).

Perhaps one thing that would help is a succinct explanation of why
inotify is insufficient, because with dnotify being marginal functional
yet merged, inotify being worked on and this, all overlapping, the
obvious questions will be around consolidating work.  In fact, something
that clearly states the requirements would be a good starting point.

Sorry I haven't had much time to review this lately ;-(

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net