On Tue, Oct 18, 2005 at 17:06 -0700, Jonathan Stone wrote:
> 
> Just out of curiosity: have you considered using FiST as a template
> (no pun intended) for a modular, extensible VFS layer?

Yes.  Well, I did not myself, but the Dazuko maintainer had a look at
FiST more than a year ago.  And quite a few months (half a year?) ago a
czech student was looking for a diploma thesis subject and wanted to
(re)attck the VFS approach so he was pointed into that direction.  But I
haven't heard anything of him since then, don't even know if he chose to
pick this subject.

> FiST is the brainchild of Erez Zadok, who was (if memory serves)
> maintainer/re-author of the BSD automount daemon. FiST wrapfs
> templates exist for FreeBSD-4 through (more or less) FreeBSD-6.
> 
> The VFS layer in FreeBSD-4 shares a recent common ancestor with
> NetBSD; if nothing else, it might be a useful starting point.
> 
> (Disclaimer: it's no secret that a NetBSD port of FiST is something
> I'd like to see happen. I'd also like to see informed commentary on
> the changes to the FreeBSD VFS layer that Erez says are necessary to
> sport file-system virtualization. Maybe our VFS could use similar
> changes; maybe we already have the equivalents.  I dunno, I don't know
> enough about the details to say one way or the other.)

It looked like the FiST project had been discontinued.  It did not run
on current distributions (software as of two or three years ago).  So
one probably would have to pick up and revive the project (fix/upgrade
the code) and keep maintaining it later, while the benefit would have
been to "just" switch Dazuko to an interface into the kernel which
already worked with a different implementation (syscall hooking -- from
what I have learned in this thread this only applies for a certain
definition of "working" :-/ ).  FiST may have other uses or priorities,
but that's what our perspective was around this time.  Other developers
with not so special an application may have more demand to pick up FiST.

I cannot tell by heart which platforms are supported by FiST.  Or if it
uses filenames (real filenames from the directory tree perspective, not
pseudo filenames merely transporting an internal representation) and
thus has the problems that come with them.  It's only since this thread
that I got aware of the issues I could not even imagine before. :)

Let me have a deeper look into the approach discussed here (generate
pseudo filenames for the vnode the vop was called for, hand these pseudo
filenames up into the userland, catch them in the kernel by hooking the
lookup vop should the userland daemon try to access this file, achieve
this "special namespace" by means of a special directory in the VFS
root).  And let me compare this to what FiST does.  Or whether FiST can
be made doing this.  I understand that the advantage of FiST is that
it's cross platform, while my current implementation will be NetBSD
specific.


After all I'd love to follow the VFS approach.  And use file handles to
circumvent the problems which were outlined in the previous discussion.

One might even combine this with hooking some (not all) of the syscalls
like open(2) or unlink(2) to have the real filename available which the
application was using.  This way even loggers and rule set based access
policy daemons could keep working.  Content scanners don't care (too
much) about the real filename, they just want a handle to scan the
file's content.

And Dazuko internally already has the concept of "filename aliases".
It's possible to check multiple path names for an accessed file against
the event filter setup (see below).  Although it might be necessary to
pass more than one filename up to the checking daemon (mostly for
logging purposes).


I'm still somewhat stuck with filenames in my mind because they are a
basic concept in Dazuko:  The dazuko(4) functionality is loaded into the
kernel and in principle could cover the whole machine.  Then a Dazuko
enabled application registers with Dazuko and configures the kernel to
generate events when certain types of accesses happen in certain
subdirectories of the filesystem.  While the kernel module sees all
accesses, the "interesting" accesses are filtered out by checking path
names.

With the VFS approach the "supervise this directory tree" will be done
by loading the VFS module (which could cover the whole machine) but then
only mounting VFS layers above the directories to be supervised.  It
looks like the VFS approach could do without "real" filenames.  Except
for two situations:

It's possible to specify exceptions to the rule.  One could setup Dazuko
to generate events for all open and close accesses under /home, but NOT
under /home/quarantine.  Or supervise / (the complete fs) but NOT /dev.
Such a filter now could only be done by hooking the lookup vop and doing
the "is selected" test there.  But this would violate the abstraction
layering inside Dazuko.  Will have to think about this for quite a
while.

The more important and really problematic case is that multiple Dazuko
enabled applications can run on a machine, each with its own specific
setup.  This could not be done with VFS layer mounting.  Delivering
access events to all registered daemons for accesses in parts of the
file hierarchy which any one daemon specified to supervise would be OK
from the security perspective (check too much but not less), but still
would be non intuitive.

In addition doing the "check this tree" can be changed by the
application at will any time it likes.  Having VFS layer mounting as the
only way to control this may not be flexible enough (it is for AV
scanners, it may not be for file managers or document postprocessors
which switch their "focus" with user's activities).


To sum it up:  There is a lot to think about for the next weeks.  And
there are approaches I can follow, methods I have to explore.  Hubert
Feyrer pointed me to http://netbsd-soc.sourceforge.net/projects/userfs/
which I have to take a look at, too.

Disclaimer:  I don't expect you to solve my problems. :)  I'm grateful
for the thoughts and hints given in this thread.  Most of the above
explanation is meant to show which environment the VFS will be used in.
Current constraints may or may not be removed.  But I guess the "we need
_some_ filename" condition won't go -- unless the Dazuko enabled
applications accept the nonavailability of "real" filenames under NetBSD
and cope with the pseudo filenames and the file's content, which could
be fine for many use cases.  It may be just a communication issue to
offer filenames for being nice but to insist on them not being any hard
criterion.


virtually yours
Gerhard Sittig
-- 
     If you don't understand or are scared by any of the above
             ask your parents or an adult to help you.