[PATCH 0/5] Dynamic Pseudo Root

[J. Bruce Fields]

On Mon, Feb 18, 2008 at 10:20:26PM -0500, bfields wrote:
> There's one thing we could take from Steve's patches regardless: it
> should be simple to just allow the administrator to tell mountd to treat
> a given path as the export root.  An administrator that wanted v4
> support would still have to do the kind of mount --bind setup they do
> now, but at least they'd be able to get consistent v2/v3/v4 paths.
> That's still just an interim solution, but it'd be an easy incremental
> improvement over what we've got.

To elaborate: there are two problems:

	- The first is an outright bug: we're presenting v4 clients with
	  a namespace that's inconsistent with that seen by v2/v3
	  (mount protocol) clients.
	- The second is a usability problem: we're making administrators
	  jump through extra hoops (setting up a pseudofilesystem
	  explicitly with fsid=0 and possibly --bind mounts).

Steve's patches address both problems, by (when mountd is started with
-R):

	- remapping paths as they're presented to the mount protocol (so
	  that children of the fsid=0 export are presented to mount
	  clients using paths relative to that export rather than
	  absolute paths).  And
	- constructing a mount namespace and pseudofilesystem
	  automatically.

It's the second that's causing people the most grief.  So I think we
should reorder Steve's patches so they come in two parts, with part 1
doing the first step above, and part 2 the second.  Then we can apply
part 1 now, giving a small incremental workaround for the first bug
without committing ourselves to any solution for the second.

And then we can consider the next step.

There's a couple problems I can think of that need to be solved if we
use restricted access to the real root namespace to implement the
pseudofilesystem:

	- We need to be able to reply to readdir and lookup requests in
	  the non-exported parent filesystems.
	- We need to be able to validate filehandles in the non-exported
	  parent filesystems.  (If we get a PUTFH with a random
	  filehandle in /, we have to first check that it's a filehandle
	  for a directory on the way to one of the exported filesystems,
	  and not just some random filehandle that a malicious client
	  guessed.)

The current export cache doesn't seem sufficient on its own, as there's
no way to tell when mountd is done filling it.  (Say mountd is modified
to pass down all exported paths whenever the export table is changed.
How do we know when it's done so we can return a readdir or lookup
result, or decide that a given filehandle is not OK?)

So I think we need at least a little bit of extra interface if we want
to do that.  I'm not sure what exactly to propose.

--b.