Re: [RFC] vfs generic subtree support

[Christoph Hellwig <hch@infradead.org>]

On Tue, Feb 16, 2010 at 02:25:40PM -0500, J. Bruce Fields wrote:
> It'd allow nfsd to implement export subtrees safely.
> 
> (The current problem: there's not an easy way to determine whether an
> inode (looked up from a filehandle) is reachable from a given directory.
> So if you export a directory that isn't the root of a filesystem, you
> have an unfortunate choice:
> 
> 	- turn on the "subtree_check" export option: add information
> 	  sufficient to lookup the parent directory to each filehandle.
> 	  But then filehandles change (and clients get ESTALE) on
> 	  cross-directory rename.
> 
> 	- Accept the possibility that someone could fake up a filehandle
> 	  that grants access to files outside the exported subtree.  OK
> 	  if you're exporting the subtree just for convenience, but bad
> 	  if you're exporting /usr/local and think /etc/some-secret is
> 	  safe without /usr/local being on a separate partition.
> 
> With subtrees presumably we could stick the subtree-id in the
> filehandle, and the subtree would provide a security boundary that's
> easy to check on filehandle lookup (by comparing the subtree-id in the
> filehandle to the one in the inode you find).  And subtrees would be
> simpler to manage than separate partitions.)

NFS exporting is in fact the reason why the XFS hierachial project
quotas were added, but only for space usage accounting and enforcement
reason.  Adding the project ID to the file handles does indeed sound
like a good idea, I'll see if it's easily implementable.

Note that in the end the best idea would be to simply allow mounting
multiple of these roots inside a single superblock.  David Howell's
infrastructure for sharing a nfs superblock for multiple blocks
allows this, and I even implemented prototypes of this for ext2 and
xfs, and a rather mutilated version of my patches is still in btrfs.

> 
> --b.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
---end quoted text---