Re: [LSF/MM TOPIC][LSF/MM ATTEND] Parent pointer future use cases

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

On Wed, Jan 31, 2018 at 06:09:43PM +0200, Amir Goldstein wrote:
> On Wed, Jan 31, 2018 at 5:30 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > On Wed, Jan 31, 2018 at 09:34:52AM +0200, Amir Goldstein wrote:
> >> If filesystem were to provide a parents iterator interface, something like:
> >> get_acceptable_parent(child, acceptable, context)
> >> then xfs could iterate inode parents and call the nfsd_acceptable() callback.
> >> For filesystems that support get_acceptable_parent(), there is no need to
> >> encode a 'connectable' non unique file handle.
> >>
> >> I am not sure how much of a problem the 'subtree_check' and non-unique
> >> file handle is for nfsd (CC nfsd folks for that), but I know I can make good use
> >> of that in overlayfs, as well as with an optimized get_name() implementation.
> >
> > I hate subtree-checking and wish people would just stop trying to export
> > subtrees.
> >
> > That said, anything that makes it less painful is probably good.
> >
> > And, yes, the fact that filehandles can change when a file is renamed
> > across directories can be a problem for people using subtree checking.
> >
> 
> Let's talk about your feeling about 'subtree_check' ...
> 
> I hate security in general and wish that users would let us develop cool
> stuff and stop worrying so much about their hopeless quest for secure
> systems ;-)

I wasn't clear.  I agree that we need subtree-checking as long as we
allow exports of subtrees.  What I dislike is exporting subtrees in the
first place.  If you only export entire superblocks, enforcement of
export access becomes much simpler and more reliable.

> The question is: is the interface I proposed going to be adequate for
> 'subtree_check' requirement. Meaning, with current 'subtree_check'
> implementation, the decoded dentry is guarantied to have the same
> parent that was used for encoding the non-dir, although it does not
> guaranty to get the exact same alias. With the interface I proposed
> get_acceptable_parent() could decode an alias that is not even
> under the original parent directory. Do you see that as a problem?

That happens in the non-subtree-check case.  Filehandles really identify
inodes, not dentries.  We map them to dentries because we need to, but
the choice is fairly arbitrary.  As long as we're able to enforce
subtree_check, we're fine.  Iterating through the list of parents until
we find one that's under the export root sounds like it should
accomplish that.

--b.