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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
