[PATCH 0/5] Dynamic Pseudo Root

[Gabriel Barazer]

On 02/19/2008 1:14:10 AM +0100, Trond Myklebust 
<trond.myklebust at fys.uio.no> wrote:
> 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.

Is the process of checking security credentials a performance issue? The 
only other way is to have a separate pseudo root for each client 
definition (a.k.a. a-sort-of-multiple-namespaces?) but that could be a 
limitation in the case of a real persistent filesystem (what about 
systems with hundreds or thousand of clients definitions/exports?). But 
I agree I had not taken the per-user granularity into account.

>> 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)?

(I don't list the "." and ".." entries)

1.
client1 readdir "/": "foo"
client1 readdir "/foo": "bar"
client1 readdir "/foo/bar": everything in this dir

client2 readdir "/": "foo"
client2 readdir "/foo": "bar"
client2 readdir "/foo/bar": "baz"

client3 readdir "/": "test"
client3 readdir "/foo": not exist (because not exported, and a 
permission error would be conceptually wrong because something not 
exported cannot exist for client3)
client3 readdir "/foo/bar": not exist

2.
it's not. Visibility would be enforce in a nfs "access control" layer. 
bind mounts would be helping creating filehandles. I'm not sure if this 
is the best way to do so.

Gabriel