On Tue, Oct 18, 2005 at 21:33 +0200, Hubert Feyrer wrote:
> 
> On Tue, 18 Oct 2005, Jason Thorpe wrote:
> >>What, exactly, would you use this for?  Path->vnode bindings are 
> >>ephemeral and
> >>cannot be relied on for much without introducing security holes.
> >
> >There are applications where:
> >
> >1- You might want to provide the path name in a log message for 
> >informational purposes.
> >
> >2- Record the path name for future use.
> 
> I think that the original poster hat something like "access control" in 
> his mind (after looking at the webpage), applying per-path rules based on 
> (open) files.

Yes, access control was the context my problems came up in, logging may
be a nice byproduct.  I'm not sure which other uses of
http://www.dazuko.org could grow killer applications, in theory anything
is possible.  Dazuko is similar to the kqueue mechanism but actually is
much more direct (not delayed, async or queued) with not just
notification but with access control on top.  So the application may not
just log and postprocess accesses but may filter them as well.  On
access AV scans may just be the most prominent example of what Dazuko
can do for your distribution.


Actually I don't have an idea why vn_fullpath() or vn_getpath() were
introduced in FreeBSD or MacOS X, it's just that I noticed their
presence and liked the idea of not having to reinvent this function. :)

But since neither the OS provides this routine nor am I able to
implement it myself in a reliable way, it may be that the VFS layer
approach won't allow for providing resolved filenames as a parameter
related to a file access (vnode operation).  This would mean that I had
to hook syscalls and lookup the files' names from their fd number for
this process.  Although I did not want to take this route because VFS
stacking felt more transparent and a cleaner solution.

I'd still love to stick with the VFS approach when getting the filename
(one or multiple, or none in the situations where this applies) for a
vnode is possible.  If it's possible then I'd like to solve the problems
described in my opening message (how to syncronize v_nclist accesses,
how to resolve long pathname components not held in the cache).


I yet have to look at the FreeBSD and Darwin implementations of their
resolving routines.  FreeBSD source is available to me, Darwin is not
because I may be a little stupid but am totally unable to grok which of
the hundred archives linked from the http://developer.apple.com/darwin/
download page is the kernel source tree.  But that's a different story.
Oh, and Linux has the d_path() which I did not yet look at either.

To reduce the potential windows of undetermined behaviour outlined in
previous responses let me show you my view on the subject:
- The open vop should reference a vnode which at this moment has a
  filename -- after all the lookup for the filename just succeeded.  I'm
  not sure how much time can pass between the lookup and the open vop
  and if other filesystem activity (like unlinking this very filename)
  may happen in between.  If this can happen then there's a race.  I'm
  not sure if the cache can provide the information which otherwise
  would be missing.
- The close vop would reference a vnode which still has a filename (i.e.
  the file can be looked up in the directory entries) so the Dazuko
  userland daemon can access this file.  Or the file (its last direntry)
  was unlinked, the filename for the vnode cannot be resolved but
  neither needs to be because there is nothing the userland daemon could
  look at.  In addition the benefit of "disallowing close(2)" is
  questionable.
- There is no exec vop for vnodes, this action will result in open, read
  and close vops which are handled in their respective vop hooks
  already.
- The unlink, rmdir und rename hooks do refer to vnodes which have a
  filename.

These are the vops I'm currently interested in.  Of course am I biased
regarding the usefulness of having a vn_fullpath() routine and the
dazuko(4) device available in NetBSD. :)  Maybe other developers see
their projects benefit from this project, too?  Many desktop users
probably would like to find working on access AV scanners or an undelete
feature or automatically indexing / postprocessing saved documents or
some similar feature.


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.