[PATCH 0/5] Dynamic Pseudo Root

[Gabriel Barazer]

Hi,

On 02/18/2008 7:25:02 PM +0100, Trond Myklebust 
<trond.myklebust at fys.uio.no> wrote:
> On Mon, 2008-02-18 at 12:12 -0500, Steve Dickson wrote:
>> Trond Myklebust wrote:
>>> On Mon, 2008-02-18 at 07:32 -0500, Steve Dickson wrote:

> You can't rely on that, though. Yes, it might work if you reboot with no
> additional changes in /dev, initramfs, and all the other tmpfs
> filesystems that get started before NFS is started, but just something
> as innocuous as plugging in a usb drive before you reboot will mess that
> up.
> Rebuilding your pseudo-filesystem after changing the export list will
> certainly screw things up quite royally.
> 
>>> IMO, the correct model for dealing with a pseudo-fs is the one that
>>> Brent described, in which you use the real fs as a base, but black out
>>> access to all non-directory dentries, and to all directory dentries that
>>> are not listed as being visible to the client by the export list.
>> Well this also carries the wait of pumping down the entire export list
>> to the kernel, which is something Bruce and I wanted to avoid since
>> thats a major change...
> 

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.

Once again, maybe this is totally impossible or pure meaningless 
thoughts, but the idea might be worth it, isn't it?

Gabriel