[PATCH 0/5] Dynamic Pseudo Root

[Gabriel Barazer]

On 02/18/2008 7:58:36 PM +0100, Trond Myklebust 
<trond.myklebust at fys.uio.no> wrote:
> On Mon, 2008-02-18 at 19:38 +0100, Gabriel Barazer wrote:
> 
>> Maybe I'm completely wrong here, but how about having a v4rootfs 
>> pseudo-filesystem ? This fs could have autogenerated directories built 
>> with the export list and a fixed fsid to not break handles. Sure you 
>> would have to put the export list into the kernel but only in this 
>> filesystem code, not in the NFS mount code. This way you don't bloat the 
>> current code, and gain the advantages of having a pseudofilesystem. 
>> There is IMHO a real problem of having an external pseudoroot fs in 
>> Linux for NFSv4 and the tmpfs/bind/using-a-real-fs-for-pseudoroot tricks 
>> are more workarounds than real solutions. The cleaner way would be to 
>> let the pseudofs handle that.
> 
> Why would this be any better than just using the real fs? Currently the
> real information about who is allowed to see what is carried by the
> _export list_, not the filesystem. By pushing information about
> visibility into the filesystem, you are restricting the export list
> topologies that can be supported.

AFAIK, you can define only one pseudoroot fs for all the NFSv4 clients, 
so you have only one namespace to "export", right? What we do with a 
real filesystem is creating directories and mount/binding them into a 
single directory defined as a pseudoroot fs. Having different 
permissions or visibility rules for the clients doesn't matter: you have 
to create all the mount/bind directories. For example:
/foo       client1
/bar	   client2

You have to create "foo" and "bar" mounts into your pseudo root fs. The 
better part with a pseudo fs instead of a real one is that you don't 
have to manage all the directories and mount points by yourself since is 
it autogenerated, and you don't have to check the consistency 
(missing/removed mountpoints) of this pseudo root at startup (you have 
to with a real fs).

> 
> For instance, currently with NFSv3, I can have rules like
> 
> /foo/bar	client1
> /foo/bar/baz	client1, client2
> 
> How can you encode this topology if you want the pseudo-fs to be a
> separate filesystem? You'd have to have 2 different namespaces, one for
> client1, and one for client2.

As I see only one namespace, I see this topology as a one namespace with 
  access control on each export. The filesystem part can easily manage 
all the directories which have to be in the pseudo root fs (because it 
is filesystem semantics), but it does not have to manage the nfs 
per-client "visibility" because it's not the same semantics.

What I have in mind is a pseudoroot fs layer managing automatically all 
the exports directories, thus creating a pseudo root with all the 
necessary mountpoints/bindings, and a second ACL layer managed by mountd 
(maybe not, see remark) . At this level it is easy to check if one 
client has rights to "see" a given export in our pseudo root. This way 
you would have one consistent namespace made of all the exports, and you 
manage the visibility at a higher level (and no client changes!).

Remark: I'm not sure about how to have the ACL layer working for NFS 
calls like READDIR on the pseudoroot fs, and if this doesn't involve 
mountd (and I guess it doesn't), we have to put it somewhere else.

About your example:
pseudoroot fs contains /foo/bar only (as /foo/bar/baz is a subdirectory 
of /foo/bar, it is supposed to already physically exist). client1 see 
its authorized exports, as well as client2 will see /foo/bar, but will 
only be allowed to mount /foo/bar/baz. If we had a third export 
"/foo/foobar2      client3", the pseudo root fs would contain 
/foo/foobar2, but this export would be only visible by client3 (mountd 
could return "not allowed" or "not exist" for the other clients, the 
latter being IMO the proper return code).

Maybe we could also add a check to mount/bind the directories in the 
right order, and/or check if the exported directory exists.

Multiple namespaces would be justified only if we had something like 
exports with the same name and different client access, but I don't 
think this is conceptually possible (and this would be a big mess!)

Maybe I'm totally unrealistic/wrong about the whole concept of the 
pseudoroot fs ? (one namespace, different permissions including the 
"visibility").

Gabriel