qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH] block/nfs: add support for setting


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] block/nfs: add support for setting debug level
Date: Thu, 25 Jun 2015 14:18:06 +0100
User-agent: Mutt/1.5.23 (2014-03-12)

On Tue, Jun 23, 2015 at 10:12:15AM +0200, Peter Lieven wrote:
> upcoming libnfs versions will support logging debug messages. Add
> support for it in qemu through an URL parameter.
> 
> Signed-off-by: Peter Lieven <address@hidden>
> ---
>  block/nfs.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/block/nfs.c b/block/nfs.c
> index ca9e24e..f7388a3 100644
> --- a/block/nfs.c
> +++ b/block/nfs.c
> @@ -329,6 +329,10 @@ static int64_t nfs_client_open(NFSClient *client, const 
> char *filename,
>          } else if (!strcmp(qp->p[i].name, "readahead")) {
>              nfs_set_readahead(client->context, val);
>  #endif
> +#ifdef LIBNFS_FEATURE_DEBUG
> +        } else if (!strcmp(qp->p[i].name, "debug")) {
> +            nfs_set_debug(client->context, val);
> +#endif
>          } else {
>              error_setg(errp, "Unknown NFS parameter name: %s",
>                         qp->p[i].name);

Untrusted users may be able to set these options since they are encoded
in the URI.  I'm imagining a hosting or cloud scenario like OpenStack.

A verbose debug level spams stderr and could consume a lot of disk
space.

(The uid and gid options are probably okay since the NFS server cannot
trust the uid/gid coming from QEMU anyway.)

I think we can merge this patch for QEMU 2.4 but I'd like to have a
discussion about the security risk of encoding libnfs options in the
URI.

CCed Eric Blake in case libvirt is affected.

Has anyone thought about this and what are the rules?

Attachment: pgp8yNkb1g7Eg.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]