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

J. Bruce Fields bfields at fieldses.org
Fri Aug 28 19:45:40 UTC 2015


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

--b.


More information about the Containers mailing list