From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58637) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bccpW-0008Bt-8m for qemu-devel@nongnu.org; Wed, 24 Aug 2016 14:23:15 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bccpR-0000X0-3G for qemu-devel@nongnu.org; Wed, 24 Aug 2016 14:23:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:46822) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bccpQ-0000Wq-Tp for qemu-devel@nongnu.org; Wed, 24 Aug 2016 14:23:09 -0400 Date: Wed, 24 Aug 2016 21:23:04 +0300 From: "Michael S. Tsirkin" Message-ID: <20160824212249-mutt-send-email-mst@kernel.org> References: <147204811781.25757.13905475486785615296.stgit@bahia.lan> <20160824154610.akhcfo32yks2m2nv@redhat.com> <20160824184145.12b37f9d@bahia.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160824184145.12b37f9d@bahia.lan> Subject: Re: [Qemu-devel] [PATCH] 9pfs: disallow / in path components List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Greg Kurz Cc: Peter Maydell , QEMU Developers , Felix Wilhelm , P J P , "Aneesh Kumar K.V" On Wed, Aug 24, 2016 at 06:41:45PM +0200, Greg Kurz wrote: > On Wed, 24 Aug 2016 18:46:10 +0300 > "Michael S. Tsirkin" wrote: > > > On Wed, Aug 24, 2016 at 04:00:24PM +0100, Peter Maydell wrote: > > > On 24 August 2016 at 15:29, Greg Kurz wrote: > > > > At various places in 9pfs, full paths are created by concatenating a guest > > > > originated string to the export path. A malicious guest could forge a > > > > relative path and access files outside the export path. > > > > > > > > A tentative fix was sent recently by Prasad J Pandit, but it was only > > > > focused on the local backend and did not get a positive review. This patch > > > > tries to address the issue more globally, based on the official 9P spec. > > > > > > > > The walk request described in the 9P spec [1] clearly shows that the client > > > > is supposed to send individual path components: the official linux client > > > > never sends portions of path containing the / character for example. > > > > > > > > Moreover, the 9P spec [2] also states that a system can decide to restrict > > > > the set of supported characters used in path components, with an explicit > > > > mention "to remove slashes from name components". > > > > > > > > This patch introduces a new name_has_illegal_characters() helper that looks > > > > for such unwanted characters in strings sent by the client. Since 9pfs is > > > > only supported on linux hosts, only the / character is checked at the > > > > moment. When support for other hosts (AKA. win32) is added, other chars > > > > may need to be blacklisted as well. > > > > > > Do we also need ".." and "." to be illegal names (for at least most > > > operations)? > > > > > > thanks > > > -- PMM > > > > I agree, and I think this implies name_is_legal would be a better function name. > > > > No I think this is a different issue that calls for a followup patch (see my > other mail). OK, that's fine. -- MST