From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48689) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bevUT-0007yL-Tm for qemu-devel@nongnu.org; Tue, 30 Aug 2016 22:43:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bevUN-0003nV-Uu for qemu-devel@nongnu.org; Tue, 30 Aug 2016 22:43:00 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:49961 helo=mx0a-001b2d01.pphosted.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bevUN-0003nP-QV for qemu-devel@nongnu.org; Tue, 30 Aug 2016 22:42:55 -0400 Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u7V2WumR071823 for ; Tue, 30 Aug 2016 22:42:55 -0400 Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by mx0b-001b2d01.pphosted.com with ESMTP id 255p3v9ku1-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 30 Aug 2016 22:42:54 -0400 Received: from localhost by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 30 Aug 2016 20:42:54 -0600 From: "Aneesh Kumar K.V" In-Reply-To: <23f1a214-da76-7bda-d464-20f4d55def25@redhat.com> References: <147257704749.28515.17213711886150247423.stgit@bahia.lab.toulouse-stg.fr.ibm.com> <147257705420.28515.6347449121724165834.stgit@bahia.lab.toulouse-stg.fr.ibm.com> <23f1a214-da76-7bda-d464-20f4d55def25@redhat.com> Date: Wed, 31 Aug 2016 08:12:45 +0530 MIME-Version: 1.0 Content-Type: text/plain Message-Id: <87k2exslp6.fsf@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v4 1/3] 9pfs: forbid illegal path names List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake , Greg Kurz , qemu-devel@nongnu.org Cc: Peter Maydell , P J P , Felix Wilhelm , "Michael S. Tsirkin" Eric Blake writes: > [ Unknown signature status ] > On 08/30/2016 12:11 PM, Greg Kurz wrote: >> Empty path components don't make sense for most commands and may cause >> undefined behavior, depending on the backend. >> >> Also, 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_is_illegal() helper that checks the >> names sent by the client are not empty and don't contain unwanted chars. >> 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. >> >> If a client sends an illegal path component, the request will fail and >> ENOENT is returned to the client. >> >> [1] http://man.cat-v.org/plan_9/5/walk >> [2] http://man.cat-v.org/plan_9/5/intro >> >> Suggested-by: Peter Maydell >> Signed-off-by: Greg Kurz >> --- >> v4: dropped the checking of the symbolic link target name: because a target >> can be a full path and thus contain '/' and linux already complains if >> it is an empty string. When the symlink gets dereferenced, slashes are >> interpreted as the usual path component separator. > > Can a symlink to "/foo" be used to escape the root (by being absolute > instead of relative)? However, if the answer to that question requires > more code, I'm fine with it being a separate patch. So for this email, We resolve "/foo" on the client side. So this is ok. -aneesh