From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56968) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beogr-0004g1-SW for qemu-devel@nongnu.org; Tue, 30 Aug 2016 15:27:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1beogn-0003eb-Ea for qemu-devel@nongnu.org; Tue, 30 Aug 2016 15:27:20 -0400 Received: from mo179.mail-out.ovh.net ([178.32.228.179]:45140) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1beogn-0003eU-4I for qemu-devel@nongnu.org; Tue, 30 Aug 2016 15:27:17 -0400 Received: from player698.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 4ACBB1004AE7 for ; Tue, 30 Aug 2016 21:27:15 +0200 (CEST) Date: Tue, 30 Aug 2016 21:27:05 +0200 From: Greg Kurz Message-ID: <20160830212705.52840d45@bahia.lan> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/gOin/kbRIl5AY.uPImMh_X3"; protocol="application/pgp-signature" 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 Cc: qemu-devel@nongnu.org, Peter Maydell , Felix Wilhelm , "Michael S. Tsirkin" , P J P , "Aneesh Kumar K.V" --Sig_/gOin/kbRIl5AY.uPImMh_X3 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 30 Aug 2016 13:03:40 -0500 Eric Blake wrote: > 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. > >=20 > > 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. > >=20 > > Moreover, the 9P spec [2] also states that a system can decide to restr= ict > > the set of supported characters used in path components, with an explic= it > > mention "to remove slashes from name components". > >=20 > > 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 add= ed, > > other chars may need to be blacklisted as well. > >=20 > > If a client sends an illegal path component, the request will fail and > > ENOENT is returned to the client. > >=20 > > [1] http://man.cat-v.org/plan_9/5/walk > > [2] http://man.cat-v.org/plan_9/5/intro > >=20 > > Suggested-by: Peter Maydell > > Signed-off-by: Greg Kurz > > --- > > v4: dropped the checking of the symbolic link target name: because a ta= rget > > 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. =20 >=20 > Can a symlink to "/foo" be used to escape the root (by being absolute No it can't because the target isn't a actually a file name but a string th= at will be translated to a path when the link is dereferenced. And all other requests with a file name argument that could have some unwanted effect don= 't allow '/' in file names. > 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, >=20 > Reviewed-by: Eric Blake >=20 --Sig_/gOin/kbRIl5AY.uPImMh_X3 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfF3goACgkQAvw66wEB28LwAgCgjEtZDv7iBgh6DzFGIjy53fUb OJ8AoI+aDZwvugfyqWCX9KkO4cuKdFpC =EzwQ -----END PGP SIGNATURE----- --Sig_/gOin/kbRIl5AY.uPImMh_X3--