From mboxrd@z Thu Jan  1 00:00:00 1970
From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH review 6/6] vfs: Cache the results of path_connected
Date: Fri, 28 Aug 2015 15:45:40 -0400
Message-ID: <20150828194540.GF10468@fieldses.org>
References: <874moq9oyb.fsf_-_@x220.int.ebiederm.org>
 <871tfkawu9.fsf_-_@x220.int.ebiederm.org>
 <8738009i0h.fsf_-_@x220.int.ebiederm.org>
 <20150804115215.GA317@odin.com>
 <871tfj0x4j.fsf@x220.int.ebiederm.org>
 <20150804194447.GB6664@fieldses.org>
 <874mkey824.fsf@x220.int.ebiederm.org>
 <20150805155948.GD17797@fieldses.org>
 <878u9pwvg8.fsf@x220.int.ebiederm.org>
 <20150828194302.GE10468@fieldses.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Andrew Vagin <avagin@gmail.com>,
	Linux Containers <containers@lists.linux-foundation.org>,
	linux-fsdevel@vger.kernel.org, Al Viro <viro@ZenIV.linux.org.uk>,
	Andy Lutomirski <luto@amacapital.net>,
	"Serge E. Hallyn" <serge@hallyn.com>,
	Richard Weinberger <richard@nod.at>,
	Andrey Vagin <avagin@openvz.org>, Jann Horn <jann@thejh.net>,
	Willy Tarreau <w@1wt.eu>, Omar Sandoval <osandov@osandov.com>,
	Miklos Szeredi <miklos@szeredi.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from fieldses.org ([173.255.197.46]:46496 "EHLO fieldses.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1752514AbbH1Tpk (ORCPT <rfc822;linux-fsdevel@vger.kernel.org>);
	Fri, 28 Aug 2015 15:45:40 -0400
Content-Disposition: inline
In-Reply-To: <20150828194302.GE10468@fieldses.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

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.