From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37569) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1be3m9-0001Ah-Ds for qemu-devel@nongnu.org; Sun, 28 Aug 2016 13:21:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1be3m5-0008Oy-4c for qemu-devel@nongnu.org; Sun, 28 Aug 2016 13:21:40 -0400 Received: from 9.mo6.mail-out.ovh.net ([87.98.171.146]:46148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1be3m4-0008Om-S0 for qemu-devel@nongnu.org; Sun, 28 Aug 2016 13:21:37 -0400 Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 72DB4FF97C4 for ; Sun, 28 Aug 2016 19:21:35 +0200 (CEST) Date: Sun, 28 Aug 2016 19:21:25 +0200 From: Greg Kurz Message-ID: <20160828192125.1f1ad6f9@bahia.lan> In-Reply-To: <57C091D5.6050101@redhat.com> References: <147222401281.18925.1894824578752486297.stgit@bahia.lan> <147222405454.18925.2135759955496138955.stgit@bahia.lan> <57C091D5.6050101@redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/hJfUus9Sr++vNV8awr/tunm"; protocol="application/pgp-signature" Subject: Re: [Qemu-devel] [PATCH v2 5/5] 9p: forbid empty extension string 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_/hJfUus9Sr++vNV8awr/tunm Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 26 Aug 2016 14:00:37 -0500 Eric Blake wrote: > On 08/26/2016 10:07 AM, Greg Kurz wrote: > > A buggy guest using the 9p2000.u protocol can issue a create request and > > pass an empty string as the extension argument. This causes QEMU to cra= sh > > in the case of a hard link or a special file, and leads to undefined > > behavior, depending on the backend, in the case of a symbolic link. > >=20 > > This patch causes the request to fail with EINVAL in these scenarios. > >=20 > > Signed-off-by: Greg Kurz > > --- Wait... empty strings coming from pdu_unmarshal() never have data =3D=3D NU= LL so this whole patch is pointless :) and BTW, only the symlink case is about file names. > > hw/9pfs/9p.c | 21 +++++++++++++++++++-- > > 1 file changed, 19 insertions(+), 2 deletions(-) > >=20 > > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c > > index 7b1dfe4e47cb..dc65c3125006 100644 > > --- a/hw/9pfs/9p.c > > +++ b/hw/9pfs/9p.c > > @@ -2150,6 +2150,11 @@ static void v9fs_create(void *opaque) > > } > > fidp->fid_type =3D P9_FID_DIR; > > } else if (perm & P9_STAT_MODE_SYMLINK) { > > + if (extension.data =3D=3D NULL) { > > + err =3D -EINVAL; > > + goto out; > > + } =20 > I realize that this part belongs to patch 1 actually: it is the implementat= ion of symbolic links that comes with 9P2000.u (different from the TSYMLINK reques= t in 9P2000.L). In which case, the hunk would have been: + if (name_is_illegal(extension.data)) { + err =3D -EINVAL; + goto out; + } > POSIX specifically requires implementations to support creating a > symlink whose target is the empty string. Linux doesn't [yet] permit > it, but BSD does. On systems where creating such a symlink is legal, > POSIX requires that such a symlink either be treated as "." if > dereferenced, or be treated as ENOENT on attempt to dereference. But > since such links can be created, readlink() should be able to read them > without error. >=20 > I would argue that we should NOT forbid empty symlinks on creation (but > pass back any error from the underlying host OS); but instead check that > dereferencing such a symlink behaves sanely if it was created. > Meanwhile, a client should not be relying on the behavior (since Linux > disobeys POSIX, portable clients should already be avoiding empty symlink= s). >=20 > http://austingroupbugs.net/view.php?id=3D649 >=20 Indeed, maybe we should let the backend decide if it allows symlink with an empty target, since the target name is simply "stored" somewhere and not used to create a new path. In which case, we should do the same with v9fs_symlink(). And we would have two exceptions to the name_is_illegal() helper, because we still want to avoid '/' in file names... On the other hand, we only support linux hosts where the call to symlink() will fail with ENOENT and guests using the official linux kernel 9p client never send an empty target... For the sake of simplicity, I'd rather have the target names to follow the same rules as other file names, and return ENOENT directly (the link you provide states it is a valid option). Peter, Since you suggested to do explicit error checking on empty file names, do you have an opinion on the case of symlinks with an empty target ? > > @@ -2161,8 +2166,15 @@ static void v9fs_create(void *opaque) > > } > > v9fs_path_copy(&fidp->path, &path); > > } else if (perm & P9_STAT_MODE_LINK) { > > - int32_t ofid =3D atoi(extension.data); > > - V9fsFidState *ofidp =3D get_fid(pdu, ofid); > > + V9fsFidState *ofidp; > > + > > + if (extension.data =3D=3D NULL) { > > + err =3D -EINVAL; > > + goto out; > > + } =20 >=20 > Rejecting an empty destination on hard link or device creation, however, > is indeed appropriate. >=20 In the case of hard links, extension.data is a FID, not a file name. In the case of device creation, extension.data is "type major minor", not a file name again. --Sig_/hJfUus9Sr++vNV8awr/tunm Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlfDHZUACgkQAvw66wEB28Ls1gCcDTP2Cy3t8jT9BVU5+js1ZH6Z JsIAoJ4o4DcIzdSrevoXERdlHRJPyCM4 =Bqar -----END PGP SIGNATURE----- --Sig_/hJfUus9Sr++vNV8awr/tunm--