[PATCH review 6/6] vfs: Cache the results of path_connected

Eric W. Biederman ebiederm at xmission.com
Mon Aug 31 21:17:28 UTC 2015

"J. Bruce Fields" <bfields at fieldses.org> writes:

> On Fri, Aug 28, 2015 at 03:43:02PM -0400, J. Bruce Fields wrote:
>> On Wed, Aug 05, 2015 at 11:28:55AM -0500, Eric W. Biederman wrote:
>> > The file handle reconstitution code can certainly be affected by all of
>> > this.  Given that it is an failure if reconnect_path can't reconnect the
>> > path of a file handle.  I think it can reasonably considered an error in
>> > all cases if that path is outside of an exported bind mount, but I don't
>> > know that area particularly well.  The solution might just be don't
>> > export file handles from bind mounts.
>> I don't think there's any new cause for concern here.
>> I'd quibble with the language "don't export filehandles", *if* by that
>> you mean "don't tell allow anyone to know filehandles".  They're
>> guessable, so keeping them secret doesn't guarantee much security.
>> The dangerous operation is open_by_handle, and people need to understand
>> that if you allow someone to call that then you're effectively giving
>> access to the whole filesystem.  That's always been true.  (We don't
>> really have an efficient way to determine if a non-directory is in a
>> given subtree anyway.)
>> Such filehandle-guessing attacks on NFS have long been well-understood.
>> NOSUBTREECHECK can prevent them but causes other problems, so isn't the
>> default.

Interesting.  I guess it makes sense that filehandles can be guessed.  I
wonder if a crypto variant that is resistant to plain text attacks would
be a practical defense.

We do have d_ancestor/is_subdir that is a compartively efficient way to
see if a dentry is in a given subtree.  As it does not need to perform
the permission checks I believe it would be some cheaper than the
current nfs subtree check code.  I don't know if that would avoid the
known problem with the subtree check code.  Nor do I know if it would be
cheap enough to use for every nfsd operation when a file handle is

>> So the basic rule I think is "don't allow lookup-by-filehandle (or NFS
>> export) on part of a filesystem unless you'd be willing to allow it on
>> the whole thing".
> (So in case it wasn't clear: ACK to just ignoring this, I don't think
> your (otherwise interesting) observations point to anything that needs
> fixing in the lookup-by-filehandle case.)

Thanks for looking into this.  It helps to know that someone who knows
the history of what happens with filehandles has looked at this.


More information about the Containers mailing list