From: Daniel Phillips <phillips@phunq.net>
To: tux3@tux3.org
Cc: Theodore Tso <tytso@mit.edu>, Jamie Lokier <jamie@shareable.org>,
linux-fsdevel@vger.kernel.org,
"Justin P. Mattock" <justinmattock@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [Tux3] Tux3 report: A Golden Copy
Date: Sun, 4 Jan 2009 17:10:12 -0800 [thread overview]
Message-ID: <200901041710.12435.phillips@phunq.net> (raw)
In-Reply-To: <20090104130446.GA17558@mit.edu>
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
next prev parent reply other threads:[~2009-01-05 1:10 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-31 3:35 Tux3 report: A Golden Copy Daniel Phillips
2008-12-31 7:34 ` sniper
2008-12-31 8:00 ` [Tux3] " Daniel Phillips
2008-12-31 8:14 ` Justin P. Mattock
2008-12-31 10:09 ` Martin Steigerwald
2008-12-31 17:41 ` Justin P. Mattock
2009-01-02 20:17 ` [Tux3] " Martin Steigerwald
2009-01-02 20:36 ` Justin P. Mattock
2009-01-02 22:45 ` [Tux3] " Daniel Phillips
2009-01-02 23:11 ` Justin P. Mattock
2009-01-03 1:19 ` Daniel Phillips
2009-01-03 1:32 ` Justin P. Mattock
2009-01-03 3:03 ` [Tux3] " Daniel Phillips
2009-01-03 3:39 ` Justin P. Mattock
2009-01-04 3:17 ` Jamie Lokier
2009-01-04 4:15 ` Daniel Phillips
2009-01-04 4:29 ` Justin P. Mattock
2009-01-04 13:04 ` Theodore Tso
2009-01-05 1:10 ` Daniel Phillips [this message]
2009-01-05 2:13 ` Jamie Lokier
2009-01-08 2:50 ` Daniel Phillips
2009-01-08 4:38 ` Evgeniy Polyakov
2008-12-31 8:16 ` sniper
2008-12-31 8:31 ` Dave Chinner
2008-12-31 9:40 ` Daniel Phillips
2008-12-31 14:26 ` Andi Kleen
2008-12-31 18:14 ` sniper
2008-12-31 18:18 ` sniper
2009-01-01 9:56 ` [Tux3] " Daniel Phillips
2009-01-01 14:46 ` Daniel Phillips
2009-01-01 23:58 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200901041710.12435.phillips@phunq.net \
--to=phillips@phunq.net \
--cc=jamie@shareable.org \
--cc=justinmattock@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tux3@tux3.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).