From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQwOH-0008KK-V0 for qemu-devel@nongnu.org; Mon, 18 Dec 2017 09:27:39 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQwOD-0006sN-O2 for qemu-devel@nongnu.org; Mon, 18 Dec 2017 09:27:37 -0500 Received: from 16.mo1.mail-out.ovh.net ([178.33.104.224]:58251) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eQwOD-0006r8-0m for qemu-devel@nongnu.org; Mon, 18 Dec 2017 09:27:33 -0500 Received: from player691.ha.ovh.net (gw6.ovh.net [213.251.189.206]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id E1DA8B157D for ; Mon, 18 Dec 2017 15:27:30 +0100 (CET) Date: Mon, 18 Dec 2017 15:27:26 +0100 From: Greg Kurz Message-ID: <20171218152726.391e607f@bahia.lan> In-Reply-To: <20171218141946.GB26755@redhat.com> References: <151360476094.18806.1179096997853697345.stgit@bahia.lan> <20171218141946.GB26755@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] 9pfs: deprecate handle backend List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: qemu-devel@nongnu.org, "Aneesh Kumar K.V" On Mon, 18 Dec 2017 14:19:46 +0000 "Daniel P. Berrange" wrote: > On Mon, Dec 18, 2017 at 02:46:00PM +0100, Greg Kurz wrote: > > 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 > > --- > > > > 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 FsDriverEntry *fse) > > const char *sec_model = qemu_opt_get(opts, "security_model"); > > const char *path = qemu_opt_get(opts, "path"); > > > > + warn_report("handle backend is deprecated"); > > + > > if (sec_model) { > > error_report("Invalid argument security_model specified with handle 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 not support multiple > > channel subsystems, all devices can be put into the default channel > > subsystem image. > > > > +@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. > > + > > I would suggest a slight teak to the last sentance. > > "This backend should not be used and wil be removed. The 'local' backend > is the recommended alternative" > Good idea. I'll just do that. > Regardless of whether you include this wording change though: > > Reviewed-by: Daniel P. Berrange > Thanks ! > > Regards, > Daniel