All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: berrange@redhat.com, vromanso@redhat.com, dwalsh@redhat.com,
	qemu-devel@nongnu.org, virtio-fs@redhat.com, stefanha@redhat.com
Subject: Re: [PATCH v2 2/5] virtiofsd: create lock/pid file in per user cache dir
Date: Fri, 7 Aug 2020 18:34:30 +0100	[thread overview]
Message-ID: <20200807173430.GI2780@work-vm> (raw)
In-Reply-To: <20200730194736.173994-3-vgoyal@redhat.com>

* Vivek Goyal (vgoyal@redhat.com) wrote:
> Right now we create lock/pid file in /usr/local/var/... and unprivliged
> user does not have access to create files there.

I *think* the /usr/local there is coming from the build config of your
qemu; but I'm not 100% sure whether it's just it's --preifx

> Hence, in unprivileged mode, create this file in per user cache dir
> as specified by environment variable XDG_RUNTIME_DIR.

Yes; it's interesting that qemu daemons are somewhat inconsistent in
this; most of them ask for a --pidfile to say where you want it;
but not all.

> Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> ---
>  tools/virtiofsd/fuse_virtio.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
> index 6b21a93841..1551a94757 100644
> --- a/tools/virtiofsd/fuse_virtio.c
> +++ b/tools/virtiofsd/fuse_virtio.c
> @@ -972,8 +972,21 @@ static bool fv_socket_lock(struct fuse_session *se)
>      g_autofree gchar *pidfile = NULL;
>      g_autofree gchar *dir = NULL;
>      Error *local_err = NULL;
> +    gboolean unprivileged = false;
>  
> -    dir = qemu_get_local_state_pathname("run/virtiofsd");
> +    if (geteuid() != 0)
> +        unprivileged = true;

Note qemu style guides need {'s on that.

> +    /*
> +     * Unpriviliged users don't have access to /usr/local/var. Hence
> +     * store lock/pid file in per user cache directory. Use environment
> +     * variable XDG_RUNTIME_DIR.
> +     */
> +    if (unprivileged) {
> +        dir = g_strdup_printf("%s/virtiofsd", g_get_user_runtime_dir());
> +    } else {
> +        dir = qemu_get_local_state_pathname("run/virtiofsd");
> +    }

Yeh that's OK, so with the  { fixed;

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

A few other possible thoughts:
  a) Just always use g_get_runtime_dir as the top; even for root - it
seems to come out as /root/.cache for root, which isn't terrible.
  b) Maybe put this code in qemu_get_local_state_pathname?

Dave


>  
>      if (g_mkdir_with_parents(dir, S_IRWXU) < 0) {
>          fuse_log(FUSE_LOG_ERR, "%s: Failed to create directory %s: %s",
> -- 
> 2.25.4
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK



WARNING: multiple messages have this Message-ID (diff)
From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Vivek Goyal <vgoyal@redhat.com>
Cc: berrange@redhat.com, vromanso@redhat.com, qemu-devel@nongnu.org,
	virtio-fs@redhat.com
Subject: Re: [Virtio-fs] [PATCH v2 2/5] virtiofsd: create lock/pid file in per user cache dir
Date: Fri, 7 Aug 2020 18:34:30 +0100	[thread overview]
Message-ID: <20200807173430.GI2780@work-vm> (raw)
In-Reply-To: <20200730194736.173994-3-vgoyal@redhat.com>

* Vivek Goyal (vgoyal@redhat.com) wrote:
> Right now we create lock/pid file in /usr/local/var/... and unprivliged
> user does not have access to create files there.

I *think* the /usr/local there is coming from the build config of your
qemu; but I'm not 100% sure whether it's just it's --preifx

> Hence, in unprivileged mode, create this file in per user cache dir
> as specified by environment variable XDG_RUNTIME_DIR.

Yes; it's interesting that qemu daemons are somewhat inconsistent in
this; most of them ask for a --pidfile to say where you want it;
but not all.

> Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
> ---
>  tools/virtiofsd/fuse_virtio.c | 15 ++++++++++++++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
> index 6b21a93841..1551a94757 100644
> --- a/tools/virtiofsd/fuse_virtio.c
> +++ b/tools/virtiofsd/fuse_virtio.c
> @@ -972,8 +972,21 @@ static bool fv_socket_lock(struct fuse_session *se)
>      g_autofree gchar *pidfile = NULL;
>      g_autofree gchar *dir = NULL;
>      Error *local_err = NULL;
> +    gboolean unprivileged = false;
>  
> -    dir = qemu_get_local_state_pathname("run/virtiofsd");
> +    if (geteuid() != 0)
> +        unprivileged = true;

Note qemu style guides need {'s on that.

> +    /*
> +     * Unpriviliged users don't have access to /usr/local/var. Hence
> +     * store lock/pid file in per user cache directory. Use environment
> +     * variable XDG_RUNTIME_DIR.
> +     */
> +    if (unprivileged) {
> +        dir = g_strdup_printf("%s/virtiofsd", g_get_user_runtime_dir());
> +    } else {
> +        dir = qemu_get_local_state_pathname("run/virtiofsd");
> +    }

Yeh that's OK, so with the  { fixed;

Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>

A few other possible thoughts:
  a) Just always use g_get_runtime_dir as the top; even for root - it
seems to come out as /root/.cache for root, which isn't terrible.
  b) Maybe put this code in qemu_get_local_state_pathname?

Dave


>  
>      if (g_mkdir_with_parents(dir, S_IRWXU) < 0) {
>          fuse_log(FUSE_LOG_ERR, "%s: Failed to create directory %s: %s",
> -- 
> 2.25.4
> 
-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK


  reply	other threads:[~2020-08-07 17:35 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-30 19:47 [PATCH v2 0/5] virtiofsd: Add a unprivileged passthrough mode Vivek Goyal
2020-07-30 19:47 ` [Virtio-fs] " Vivek Goyal
2020-07-30 19:47 ` [PATCH v2 1/5] virtiofsd: Add notion of unprivileged mode Vivek Goyal
2020-07-30 19:47   ` [Virtio-fs] " Vivek Goyal
2020-08-07 16:33   ` Dr. David Alan Gilbert
2020-08-07 16:33     ` [Virtio-fs] " Dr. David Alan Gilbert
2020-07-30 19:47 ` [PATCH v2 2/5] virtiofsd: create lock/pid file in per user cache dir Vivek Goyal
2020-07-30 19:47   ` [Virtio-fs] " Vivek Goyal
2020-08-07 17:34   ` Dr. David Alan Gilbert [this message]
2020-08-07 17:34     ` Dr. David Alan Gilbert
2020-07-30 19:47 ` [PATCH v2 3/5] virtiofsd: open /proc/self/fd/ in sandbox=NONE mode Vivek Goyal
2020-07-30 19:47   ` [Virtio-fs] " Vivek Goyal
2020-08-07 17:42   ` Dr. David Alan Gilbert
2020-08-07 17:42     ` [Virtio-fs] " Dr. David Alan Gilbert
2020-07-30 19:47 ` [PATCH v2 4/5] virtiofsd: Open lo->source while setting up root " Vivek Goyal
2020-07-30 19:47   ` [Virtio-fs] " Vivek Goyal
2020-08-03  9:54   ` Stefan Hajnoczi
2020-08-03  9:54     ` [Virtio-fs] " Stefan Hajnoczi
2020-08-03 13:57     ` Vivek Goyal
2020-08-03 13:57       ` [Virtio-fs] " Vivek Goyal
2020-08-04 10:36       ` Stefan Hajnoczi
2020-08-04 10:36         ` [Virtio-fs] " Stefan Hajnoczi
2020-07-30 19:47 ` [PATCH v2 5/5] virtiofsd: Skip setup_capabilities() " Vivek Goyal
2020-07-30 19:47   ` [Virtio-fs] " Vivek Goyal
2020-08-07 17:58   ` Dr. David Alan Gilbert
2020-08-07 17:58     ` [Virtio-fs] " Dr. David Alan Gilbert
2020-08-03  9:45 ` [PATCH v2 0/5] virtiofsd: Add a unprivileged passthrough mode Stefan Hajnoczi
2020-08-03  9:45   ` [Virtio-fs] " Stefan Hajnoczi

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=20200807173430.GI2780@work-vm \
    --to=dgilbert@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dwalsh@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=vgoyal@redhat.com \
    --cc=virtio-fs@redhat.com \
    --cc=vromanso@redhat.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.