[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