From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: "misono.tomohiro@fujitsu.com" <misono.tomohiro@fujitsu.com>
Cc: "vromanso@redhat.com" <vromanso@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"rmohr@redhat.com" <rmohr@redhat.com>,
"virtio-fs@redhat.com" <virtio-fs@redhat.com>,
"mpatel@redhat.com" <mpatel@redhat.com>,
"vgoyal@redhat.com" <vgoyal@redhat.com>
Subject: Re: [Virtio-fs] [PATCH v2 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error
Date: Fri, 7 Aug 2020 16:29:49 +0100 [thread overview]
Message-ID: <20200807152949.GF2780@work-vm> (raw)
In-Reply-To: <OSBPR01MB45826073E5A54CF869E56721E5730@OSBPR01MB4582.jpnprd01.prod.outlook.com>
* misono.tomohiro@fujitsu.com (misono.tomohiro@fujitsu.com) wrote:
> > Subject: [PATCH v2 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error
> >
> > An assertion failure is raised during request processing if
> > unshare(CLONE_FS) fails. Implement a probe at startup so the problem can
> > be detected right away.
> >
> > Unfortunately Docker/Moby does not include unshare in the seccomp.json
> > list unless CAP_SYS_ADMIN is given. Other seccomp.json lists always
> > include unshare (e.g. podman is unaffected):
> > https://raw.githubusercontent.com/seccomp/containers-golang/master/seccomp.json
> >
> > Use "docker run --security-opt seccomp=path/to/seccomp.json ..." if the
> > default seccomp.json is missing unshare.
>
> Hi, sorry for a bit late.
>
> unshare() was added to fix xattr problem:
> https://github.com/qemu/qemu/commit/bdfd66788349acc43cd3f1298718ad491663cfcc#
> In theory we don't need to call unshare if xattr is disabled, but it is hard to get to know
> if xattr is enabled or disabled in fv_queue_worker(), right?
>
> So, it looks good to me.
> Reviewed-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
OK, I think it might also be OK to just fail the xattr operation on a
non-file/directory in this case.
Dave
> Regards,
> Misono
>
> >
> > Cc: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> > tools/virtiofsd/fuse_virtio.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
> > index 3b6d16a041..9e5537506c 100644
> > --- a/tools/virtiofsd/fuse_virtio.c
> > +++ b/tools/virtiofsd/fuse_virtio.c
> > @@ -949,6 +949,22 @@ int virtio_session_mount(struct fuse_session *se)
> > {
> > int ret;
> >
> > + /*
> > + * Test that unshare(CLONE_FS) works. fv_queue_worker() will need it. It's
> > + * an unprivileged system call but some Docker/Moby versions are known to
> > + * reject it via seccomp when CAP_SYS_ADMIN is not given.
> > + *
> > + * Note that the program is single-threaded here so this syscall has no
> > + * visible effect and is safe to make.
> > + */
> > + ret = unshare(CLONE_FS);
> > + if (ret == -1 && errno == EPERM) {
> > + fuse_log(FUSE_LOG_ERR, "unshare(CLONE_FS) failed with EPERM. If "
> > + "running in a container please check that the container "
> > + "runtime seccomp policy allows unshare.\n");
> > + return -1;
> > + }
> > +
> > ret = fv_create_listen_socket(se);
> > if (ret < 0) {
> > return ret;
> > --
> > 2.26.2
>
--
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: "misono.tomohiro@fujitsu.com" <misono.tomohiro@fujitsu.com>
Cc: "vromanso@redhat.com" <vromanso@redhat.com>,
Daniel Walsh <dwalsh@redhat.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
"rmohr@redhat.com" <rmohr@redhat.com>,
"virtio-fs@redhat.com" <virtio-fs@redhat.com>,
'Stefan Hajnoczi' <stefanha@redhat.com>,
"mpatel@redhat.com" <mpatel@redhat.com>,
"vgoyal@redhat.com" <vgoyal@redhat.com>
Subject: Re: [PATCH v2 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error
Date: Fri, 7 Aug 2020 16:29:49 +0100 [thread overview]
Message-ID: <20200807152949.GF2780@work-vm> (raw)
In-Reply-To: <OSBPR01MB45826073E5A54CF869E56721E5730@OSBPR01MB4582.jpnprd01.prod.outlook.com>
* misono.tomohiro@fujitsu.com (misono.tomohiro@fujitsu.com) wrote:
> > Subject: [PATCH v2 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error
> >
> > An assertion failure is raised during request processing if
> > unshare(CLONE_FS) fails. Implement a probe at startup so the problem can
> > be detected right away.
> >
> > Unfortunately Docker/Moby does not include unshare in the seccomp.json
> > list unless CAP_SYS_ADMIN is given. Other seccomp.json lists always
> > include unshare (e.g. podman is unaffected):
> > https://raw.githubusercontent.com/seccomp/containers-golang/master/seccomp.json
> >
> > Use "docker run --security-opt seccomp=path/to/seccomp.json ..." if the
> > default seccomp.json is missing unshare.
>
> Hi, sorry for a bit late.
>
> unshare() was added to fix xattr problem:
> https://github.com/qemu/qemu/commit/bdfd66788349acc43cd3f1298718ad491663cfcc#
> In theory we don't need to call unshare if xattr is disabled, but it is hard to get to know
> if xattr is enabled or disabled in fv_queue_worker(), right?
>
> So, it looks good to me.
> Reviewed-by: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
OK, I think it might also be OK to just fail the xattr operation on a
non-file/directory in this case.
Dave
> Regards,
> Misono
>
> >
> > Cc: Misono Tomohiro <misono.tomohiro@jp.fujitsu.com>
> > Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
> > ---
> > tools/virtiofsd/fuse_virtio.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/tools/virtiofsd/fuse_virtio.c b/tools/virtiofsd/fuse_virtio.c
> > index 3b6d16a041..9e5537506c 100644
> > --- a/tools/virtiofsd/fuse_virtio.c
> > +++ b/tools/virtiofsd/fuse_virtio.c
> > @@ -949,6 +949,22 @@ int virtio_session_mount(struct fuse_session *se)
> > {
> > int ret;
> >
> > + /*
> > + * Test that unshare(CLONE_FS) works. fv_queue_worker() will need it. It's
> > + * an unprivileged system call but some Docker/Moby versions are known to
> > + * reject it via seccomp when CAP_SYS_ADMIN is not given.
> > + *
> > + * Note that the program is single-threaded here so this syscall has no
> > + * visible effect and is safe to make.
> > + */
> > + ret = unshare(CLONE_FS);
> > + if (ret == -1 && errno == EPERM) {
> > + fuse_log(FUSE_LOG_ERR, "unshare(CLONE_FS) failed with EPERM. If "
> > + "running in a container please check that the container "
> > + "runtime seccomp policy allows unshare.\n");
> > + return -1;
> > + }
> > +
> > ret = fv_create_listen_socket(se);
> > if (ret < 0) {
> > return ret;
> > --
> > 2.26.2
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2020-08-07 15:29 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-27 19:02 [Virtio-fs] [PATCH v2 0/3] virtiofsd: allow virtiofsd to run in a container Stefan Hajnoczi
2020-07-27 19:02 ` Stefan Hajnoczi
2020-07-27 19:02 ` [Virtio-fs] [PATCH v2 1/3] virtiofsd: drop CAP_DAC_READ_SEARCH Stefan Hajnoczi
2020-07-27 19:02 ` Stefan Hajnoczi
2020-07-27 19:02 ` [Virtio-fs] [PATCH v2 2/3] virtiofsd: add container-friendly -o sandbox=chroot option Stefan Hajnoczi
2020-07-27 19:02 ` Stefan Hajnoczi
2020-08-07 15:36 ` [Virtio-fs] " Dr. David Alan Gilbert
2020-08-07 15:36 ` Dr. David Alan Gilbert
2020-07-27 19:02 ` [Virtio-fs] [PATCH v2 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error Stefan Hajnoczi
2020-07-27 19:02 ` Stefan Hajnoczi
2020-07-28 1:05 ` [Virtio-fs] " misono.tomohiro
2020-07-28 1:05 ` misono.tomohiro
2020-07-28 10:00 ` [Virtio-fs] " Roman Mohr
2020-07-28 10:00 ` Roman Mohr
2020-07-28 13:12 ` [Virtio-fs] " Vivek Goyal
2020-07-28 13:12 ` Vivek Goyal
2020-07-28 15:52 ` [Virtio-fs] " Daniel P. Berrangé
2020-07-28 15:52 ` Daniel P. Berrangé
2020-07-28 20:54 ` [Virtio-fs] " Vivek Goyal
2020-07-28 20:54 ` Vivek Goyal
2020-07-28 19:12 ` [Virtio-fs] " Daniel Walsh
2020-07-28 19:12 ` Daniel Walsh
2020-07-28 21:01 ` [Virtio-fs] " Vivek Goyal
2020-07-28 21:01 ` Vivek Goyal
2020-07-29 7:59 ` [Virtio-fs] " Roman Mohr
2020-07-29 7:59 ` Roman Mohr
2020-07-29 14:40 ` [Virtio-fs] " Stefan Hajnoczi
2020-07-29 14:40 ` Stefan Hajnoczi
2020-07-30 22:21 ` [Virtio-fs] " Daniel Walsh
2020-07-30 22:21 ` Daniel Walsh
2020-07-31 8:26 ` [Virtio-fs] " Stefan Hajnoczi
2020-07-31 8:26 ` Stefan Hajnoczi
2020-07-31 8:39 ` [Virtio-fs] " Roman Mohr
2020-07-31 8:39 ` Roman Mohr
2020-07-31 14:11 ` [Virtio-fs] " Stefan Hajnoczi
2020-07-31 14:11 ` Stefan Hajnoczi
2020-07-28 15:32 ` [Virtio-fs] " Stefan Hajnoczi
2020-07-28 15:32 ` Stefan Hajnoczi
2020-07-28 19:15 ` [Virtio-fs] " Daniel Walsh
2020-07-28 19:15 ` Daniel Walsh
2020-07-29 14:29 ` [Virtio-fs] " Stefan Hajnoczi
2020-07-29 14:29 ` Stefan Hajnoczi
2020-08-07 15:29 ` Dr. David Alan Gilbert [this message]
2020-08-07 15:29 ` Dr. David Alan Gilbert
2020-08-27 18:40 ` [Virtio-fs] [PATCH v2 0/3] virtiofsd: allow virtiofsd to run in a container Dr. David Alan Gilbert
2020-08-27 18:40 ` Dr. David Alan Gilbert
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=20200807152949.GF2780@work-vm \
--to=dgilbert@redhat.com \
--cc=misono.tomohiro@fujitsu.com \
--cc=mpatel@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rmohr@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.