From nobody Tue Oct 28 12:17:37 2025 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) client-ip=208.118.235.17; envelope-from=qemu-devel-bounces+importer=patchew.org@nongnu.org; helo=lists.gnu.org; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of gnu.org designates 208.118.235.17 as permitted sender) smtp.mailfrom=qemu-devel-bounces+importer=patchew.org@nongnu.org Return-Path: Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) by mx.zohomail.com with SMTPS id 1513604875074913.7283219127147; Mon, 18 Dec 2017 05:47:55 -0800 (PST) Received: from localhost ([::1]:36805 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQvlj-0003gi-P0 for importer@patchew.org; Mon, 18 Dec 2017 08:47:47 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQvkD-0002at-Si for qemu-devel@nongnu.org; Mon, 18 Dec 2017 08:46:15 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQvk9-0004ZN-Pf for qemu-devel@nongnu.org; Mon, 18 Dec 2017 08:46:13 -0500 Received: from 19.mo1.mail-out.ovh.net ([178.32.97.206]:36282) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eQvk9-0004Yo-GF for qemu-devel@nongnu.org; Mon, 18 Dec 2017 08:46:09 -0500 Received: from player691.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id D240BB2799 for ; Mon, 18 Dec 2017 14:46:06 +0100 (CET) Received: from bahia.lan (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player691.ha.ovh.net (Postfix) with ESMTPA id 1643026008E; Mon, 18 Dec 2017 14:46:01 +0100 (CET) From: Greg Kurz To: qemu-devel@nongnu.org Date: Mon, 18 Dec 2017 14:46:00 +0100 Message-ID: <151360476094.18806.1179096997853697345.stgit@bahia.lan> User-Agent: StGit/0.17.1-46-g6855-dirty MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Ovh-Tracer-Id: 14311313719493761488 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtuddrgedtgdehjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 178.32.97.206 Subject: [Qemu-devel] [PATCH] 9pfs: deprecate handle backend X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Greg Kurz , "Aneesh Kumar K.V" Errors-To: qemu-devel-bounces+importer=patchew.org@nongnu.org Sender: "Qemu-devel" X-ZohoMail: RSF_0 Z_629925259 SPT_0 This backend raise some concerns: - doesn't support symlinks - fails +100 tests in the PJD POSIX file system test suite [1] - requires the QEMU process to run with the CAP_DAC_READ_SEARCH capability, which isn't recommended for security reasons For all these reasons, the handle backend is now deprecated. [1] https://www.tuxera.com/community/posix-test-suite/ Signed-off-by: Greg Kurz Reviewed-by: Aneesh Kumar K.V --- Aneesh, Even if I see the benefit of using file handles in a userspace file server, the handle backend still has flaws that make it hardly usable IMHO. Also I haven't received anything about it in years. All users and contributors seem to stick to the local backend. My guess is that nobody uses the handle backend, and unless I'm missing something, it wouldn't hurt to drop it. My motivation is to reduce the number of lines that I don't really have time/motivation to maintain, and that could be subject to a CVE in the future. Any thoughts ? --- hw/9pfs/9p-handle.c | 2 ++ qemu-doc.texi | 8 ++++++++ 2 files changed, 10 insertions(+) diff --git a/hw/9pfs/9p-handle.c b/hw/9pfs/9p-handle.c index 9875f1894cc5..1291a2db6782 100644 --- a/hw/9pfs/9p-handle.c +++ b/hw/9pfs/9p-handle.c @@ -657,6 +657,8 @@ static int handle_parse_opts(QemuOpts *opts, struct FsD= riverEntry *fse) const char *sec_model =3D qemu_opt_get(opts, "security_model"); const char *path =3D qemu_opt_get(opts, "path"); =20 + warn_report("handle backend is deprecated"); + if (sec_model) { error_report("Invalid argument security_model specified with handl= e fsdriver"); return -1; diff --git a/qemu-doc.texi b/qemu-doc.texi index f7317dfc66cd..bf44e2752cb2 100644 --- a/qemu-doc.texi +++ b/qemu-doc.texi @@ -2509,6 +2509,14 @@ default channel subsystem image for guests that do n= ot support multiple channel subsystems, all devices can be put into the default channel subsystem image. =20 +@subsection -fsdev handle (since 2.12.0) + +The ``handle'' fsdev backend does not support symlinks and causes the 9p +filesystem in the guest to fail a fair amount of tests from the PJD POSIX +filesystem test suite. Also it requires the CAP_DAC_READ_SEARCH capability, +which is not the recommended way to run QEMU. This backend should not be +used and it will be removed with no replacement. + @section qemu-img command line arguments =20 @subsection convert -s (since 2.0.0)