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

[J. Bruce Fields]

This is response is kind of ridiculously delayed; vacation and a couple
other things interfered!:

On Wed, Aug 05, 2015 at 11:28:55AM -0500, Eric W. Biederman wrote:
> "J. Bruce Fields" <bfields at fieldses.org> writes:
> 
> > On Tue, Aug 04, 2015 at 05:58:59PM -0500, Eric W. Biederman wrote:
> >>
> >> No problem.  The basic question is: can 2Billion renames be performed on
> >> the same filesystem in less time than a single path lookup?  Allowing
> >> the use of a 32bit counter.
> >
> > Certainly if you have control over an NFS or FUSE server then you can
> > arrange for that to happen--just delay the lookup until you've processed
> > enough renames.  I don't know if that's interesting....
> 
> Not particularly when the whole point is to start with a bind mount, do
> something trick and then have access to the whole filesystem instead of
> just the part of the filesystem exposed by the bind mount.
> 
> If you control the filesystem you already have access to the entire
> filesystem, so you don't need to do something trick.

I thought there was also a concern about impact on the sanity of the
system as a whole beyond just the contents of one filesystem: e.g. you
don't want an unprivileged user to be able to create an unmountable
mountpoint.

> That something tricky is a well placed rename that borks the tree
> structure and causes .. to never see the subdirectory that is the root
> of the bind mount.
> 
> >> If you could look up thread and tell me what you think of the issue with
> >> file handle to dentry conversion and bind mounts I would be appreciate.
> >
> > OK, I see your comments in "[PATCH review 0/6] Bind mount escape fixes",
> > I'm not sure I understand yet, I'll take a closer look.
> 
> Thanks.
> 
> 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.

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

--b.