[PATCH 0/5] Dynamic Pseudo Root

[Trond Myklebust]

On Mon, 2008-02-18 at 21:52 +0100, Gabriel Barazer wrote:
> On 02/18/2008 9:09:32 PM +0100, Trond Myklebust 
> <trond.myklebust at fys.uio.no> wrote:
> > On Mon, 2008-02-18 at 20:41 +0100, Gabriel Barazer wrote:
> > 
> >> AFAIK, you can define only one pseudoroot fs for all the NFSv4 clients, 
> >> so you have only one namespace to "export", right?
> > 
> > No! That would be a regression w.r.t. NFSv2/v3.
> 
> Maybe I used the wrong words: What I am trying to say is that you will 
> not ever have one client (client1) seeing a /foo/bar export that is a 
> different directory for another client. multiple namespaces would mean 
> that they have independant export entries (=directories), and you could 
> have a /foo entry exported on client1 that is a different directory than 
> another "/foo" entry exported on client2. What we have is a "/foo" 
> export which the same directory on every allowed client, but visible or 
> not. This behavior is not a regression regarding NFSv2/3. I'm not 
> talking about having one single "export" per client.

The point is that the behaviour of that '/foo' will depend on whether or
not the directory is part of the pseudo-fs or not. That is not even a
per-client thing, it can be a per-_user_ thing if you have RPCSEC_GSS
security enabled.

> The proposed example can work with both NFSv2/3 and NFSv4 topologies. 
> Let's clear this example as well:
> exports:
> /foo/bar       client1
> /foo/bar/baz   client1, client2
> /test          client3
> 
> the pseudo fs would contain:
> /foo (or /foo/bar, depending on which directory has to be "mount --bind")
> /test

So
     1. what would 'client1', 'client2' and 'client3' actually _see_ if
        they call readdir() on '/', '/foo', and '/foo/bar' respectively?
     2. How is the bind mount helping to enforce whatever visibility
        rules you are proposing as a response to question (1)?