[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Virtio-fs] [PATCH for-5.1 2/3] virtiofsd: add container-friendly -o
From: |
Stefan Hajnoczi |
Subject: |
Re: [Virtio-fs] [PATCH for-5.1 2/3] virtiofsd: add container-friendly -o chroot sandboxing option |
Date: |
Thu, 23 Jul 2020 16:36:47 +0100 |
On Thu, Jul 23, 2020 at 09:47:33AM -0400, Vivek Goyal wrote:
> On Thu, Jul 23, 2020 at 01:28:50PM +0100, Stefan Hajnoczi wrote:
> > On Wed, Jul 22, 2020 at 06:58:20PM +0100, Dr. David Alan Gilbert wrote:
> > > * Stefan Hajnoczi (stefanha@redhat.com) wrote:
> > > > virtiofsd cannot run in an unprivileged container because CAP_SYS_ADMIN
> > > > is required to create namespaces.
> > > >
> > > > Introduce a weaker sandbox that is sufficient in container environments
> > > > because the container runtime already sets up namespaces. Use chroot to
> > > > restrict path traversal to the shared directory.
> > > >
> > > > virtiofsd loses the following:
> > > >
> > > > 1. Mount namespace. The process chroots to the shared directory but
> > > > leaves the mounts in place. Seccomp rejects mount(2)/umount(2)
> > > > syscalls.
> > >
> > > OK, I'm guessing the behaviour of what happens if the host adds another
> > > mount afterwards might be different?
> >
> > Running inside a container with -o chroot:
> > - The container has its own mount namespace and it is therefore not
> > affected, modulo shared subtrees (see mount(8)).
>
> How does virtiofsd inside container gets the directory it wants to
> export to guest? I am assuming that its probably a volume mount
> inside container. If yes, volume mounts can set propagation
> properties say "slave" and that means mounts done later will
> propagate inside container in that volume (and hopefully be
> visible inside guest once submount patches are upstream).
Yes, the shared directory is a volume mount and propagation works as
expected:
$ docker run -v path/to/shared-dir:/shared-dir:slave \
-v /tmp/socket-dir:/var/run \
virtiofsd
When I mount things in path/to/shared-dir on the host they appear in
/shared-dir inside the guest. When I omit the "slave" option (the
default is "private") then the mount does not propagate.
The following Dockerfile was used:
$ cp ~/src/qemu/virtiofsd . # copy the executable
$ cat >Dockerfile
FROM fedora:32
COPY --chown=0:0 virtiofsd /usr/bin/virtiofsd
RUN dnf update -qy && dnf install -qy libseccomp liburing zlib glib2 nettle
gnutls libcap-ng
VOLUME ["/shared-dir", "/var/run"]
CMD ["/usr/bin/virtiofsd", "--socket-path=/var/run/virtiofsd.sock", "-o",
"source=/shared-dir", "-o", "cache=auto", "-o", "no_posix_lock", "-o", "xattr",
"-o", "chroot"]
Stefan
signature.asc
Description: PGP signature
[PATCH for-5.1 3/3] virtiofsd: probe unshare(CLONE_FS) and print an error, Stefan Hajnoczi, 2020/07/22