From: "J. Bruce Fields" <bfields@fieldses.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: Dmitry Monakhov <dmonakhov@openvz.org>,
Matthew Wilcox <matthew@wil.cx>,
Al Viro <viro@ZenIV.linux.org.uk>,
linux-fsdevel@vger.kernel.org
Subject: Re: [RFC] vfs generic subtree support
Date: Tue, 16 Feb 2010 14:39:38 -0500 [thread overview]
Message-ID: <20100216193938.GC26292@fieldses.org> (raw)
In-Reply-To: <20100216193205.GA20297@infradead.org>
On Tue, Feb 16, 2010 at 02:32:05PM -0500, Christoph Hellwig wrote:
> 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.
I lost you there.
--b.
> 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.
prev parent reply other threads:[~2010-02-16 19:39 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-16 10:52 [RFC] vfs generic subtree support Dmitry Monakhov
2010-02-16 12:20 ` Al Viro
2010-02-16 12:37 ` Dmitry Monakhov
2010-02-16 13:38 ` Al Viro
2010-02-16 14:01 ` Dmitry Monakhov
2010-02-16 14:21 ` Al Viro
2010-02-16 15:00 ` Dmitry Monakhov
2010-02-16 15:12 ` Matthew Wilcox
2010-02-16 15:32 ` Dmitry Monakhov
2010-02-16 19:25 ` J. Bruce Fields
2010-02-16 19:32 ` Christoph Hellwig
2010-02-16 19:39 ` J. Bruce Fields [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100216193938.GC26292@fieldses.org \
--to=bfields@fieldses.org \
--cc=dmonakhov@openvz.org \
--cc=hch@infradead.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=viro@ZenIV.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.