From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Greg Kurz <groug@kaod.org>, qemu-devel@nongnu.org
Cc: "Daniel P. Berrange" <berrange@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] 9pfs: deprecate handle backend
Date: Mon, 08 Jan 2018 14:05:45 +0530 [thread overview]
Message-ID: <87mv1ozr1a.fsf@linux.vnet.ibm.com> (raw)
In-Reply-To: <151360476094.18806.1179096997853697345.stgit@bahia.lan>
Greg Kurz <groug@kaod.org> writes:
> 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/
>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Signed-off-by: Greg Kurz <groug@kaod.org>
> ---
>
> 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.
> +
> @section qemu-img command line arguments
>
> @subsection convert -s (since 2.0.0)
prev parent reply other threads:[~2018-01-08 8:36 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-18 13:46 [Qemu-devel] [PATCH] 9pfs: deprecate handle backend Greg Kurz
2017-12-18 14:19 ` Daniel P. Berrange
2017-12-18 14:27 ` Greg Kurz
2018-01-08 8:35 ` Aneesh Kumar K.V [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87mv1ozr1a.fsf@linux.vnet.ibm.com \
--to=aneesh.kumar@linux.vnet.ibm.com \
--cc=berrange@redhat.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).