Re: [Tux3] Tux3 report: A Golden Copy

Daniel Phillips
2009-01-05T01:10:38Z

Hi Ted,

On Sunday 04 January 2009 05:04, Theodore Tso wrote:
> On Sun, Jan 04, 2009 at 03:17:33AM +0000, Jamie Lokier wrote:
> > Justin P. Mattock wrote:
> > > >One feature we are kicking around to make life easier for SELinux:
> > > >sometimes the filesystem can run while SELinux is not running, and
> > > >security labels will be wrong when SELinux re-enters the picture. We
> > > >have in mind to provide a persistent log of filesystem events that the
> > > >security system can attach to on startup and find out what went on in
> > > >its absence.
> > > >
> > That sounds like a feature Windows had for many years now, (since
> > Windows 2000?). It complements the Windows equivlant of
> > dnotify/inotify/fsnotify.
>
> Arguably you want to do this in the VFS layer, not in the low-level
> filesystem level if you want most applications to adopt it.

It has to be generic all right, but the VFS is not able to do the job
on its own. To be useful for indexing, the reported events must
already be persistently recorded, and the VFS has no idea about when
that happens. The filesystem is the expert on that subject, and it
must generate the events. I can't imagine a reasonable VFS-level
emulation, or what value the VFS would add by acting as middleman for
a stream of filesystem events.

The natural way to do this is for the filesystem to stream events
directly to the monitoring application over a pipe-like fd. Maybe a
library for event delivery could be shared by filesystems, to impose
a standard format. The role of the VFS would be simply to set up the
event connection, or to report that it is not supported.

> > It's used for file indexing too (think equivalent to Spotlight,
> > Beagle, etc.), and other types of security scanning (think equivalent
> > to Tripwire).
>
> Eric Paris has a patch he's been proposing for a while now for a new
> notify mechanism designed for anti-virus scanners...

An event stream accurate enough to support indexing is a considerably
harder problem, I think.

Regards,

Daniel