Re: [RFC] vfs generic subtree support

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Feb 16, 2010 at 06:32:47PM +0300, Dmitry Monakhov wrote:
> Matthew Wilcox <matthew@wil.cx> writes:
> 
> > On Tue, Feb 16, 2010 at 06:00:32PM +0300, Dmitry Monakhov wrote:
> >> Use-cases:
> >> *Assing maximum disc space consumption for some hierarchy *
> >> 
> >>   1) Create chroot environment
> >>     # tar  xf chroot_env.tar /var/xxx/chroot
> >>   2) Assign some metagroup id to the chroot content (via not yet
> >>      existent ./metagroup cmd-tool)
> >>     # find /var/xxx/chroot  | xargs ./metagroup --set 1000
> >> 
> >>   3) Setup quota limits
> >>     # quota-set --type metagroup --blk_soft=1024M blk_hard=1024M /var
> >> 
> >>   4) Export this tree (it may be more complex)
> >>     # mount /var/xxx/chroot /mnt/chroot -obound
> >> 
> >>   5)Now we may use this /mnt/chroot as:
> >>     5A) A regular chroot envirement, user is unable to exceed metagroup
> >>         quota, regardless to real available space on /var/
> >>     5B) As a container's (namespace) root. 
> >>     5C) export this /mnt/chroot to nfs server and nfs client can not
> >>         overcome given metagroup quota limit. 
> >
> > This all seems quota-related ... do you envisage uses that aren't
> > quota-related?
> Yes. Since link/rename behavior is no longer depends on metagroup
> I'm consider it as quota related only.  

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

--b.