From: "Colin Walters" <walters@verbum.org>
To: "Vivek Goyal" <vgoyal@redhat.com>
Cc: "Sergio Lopez" <slp@redhat.com>,
"Stefan Hajnoczi" <stefanha@redhat.com>,
virtio-fs-list <virtio-fs@redhat.com>,
qemu-devel@nongnu.org, "German Maglione" <gmaglione@redhat.com>
Subject: Re: [Virtio-fs] virtiofsd: Any reason why there's not an "openat2" sandbox mode?
Date: Mon, 03 Oct 2022 18:51:42 -0400 [thread overview]
Message-ID: <aa26d28d-d352-467c-910c-ab5973a6d759@app.fastmail.com> (raw)
In-Reply-To: <YzXP8XhCG5ta2Dvv@redhat.com>
On Thu, Sep 29, 2022, at 1:03 PM, Vivek Goyal wrote:
>
> So rust version of virtiofsd, already supports running unprivileged
> (inside a user namespace).
I know, but as I already said, the use case here is running inside an OpenShift unprivileged pod where *we are already in a container*.
> host$ podman unshare -- virtiofsd --socket-path=/tmp/vfsd.sock
> --shared-dir /mnt \
> --announce-submounts --sandbox chroot &
Yes, but in current OCP 4.11 our seccomp policy denies CLONE_NEWUSER:
```
$ unshare -m
unshare: unshare failed: Function not implemented
```
https://docs.openshift.com/container-platform/4.11/security/seccomp-profiles.html
> I think only privileged operation it needs is assigning a range of
> subuid/subgid to the uid you are using on host.
We also turn on NO_NEW_PRIVILEGES by default in OCP pods.
Now, I *could* in general get elevated permissions where I need to today. But it's also really important to me to have a long term goal of having operating system builds and tests work well as "just another workload" in our production container platform (now, one *does* want to bind in /dev/kvm, but that's generally safe, and even that strictly speaking is optional if one can stomach the ~10x perf hit).
> Can you give rust virtiofsd (unprivileged) a try.
I admit to not actually trying it in a pod, but I think we all agree it can't work, and the only thing that can today is openat2.
next prev parent reply other threads:[~2022-10-03 22:53 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-09 21:24 virtiofsd: Any reason why there's not an "openat2" sandbox mode? Colin Walters
2022-09-27 16:37 ` Vivek Goyal
2022-09-27 16:57 ` Vivek Goyal
2022-09-27 17:27 ` German Maglione
2022-09-27 17:51 ` Colin Walters
2022-09-27 20:14 ` [Virtio-fs] " Stefan Hajnoczi
2022-09-28 8:33 ` Sergio Lopez
2022-09-28 19:28 ` Vivek Goyal
2022-09-29 14:04 ` Colin Walters
2022-09-29 14:10 ` Vivek Goyal
2022-09-29 15:47 ` Colin Walters
2022-09-29 17:03 ` Vivek Goyal
2022-09-30 8:13 ` German Maglione
2022-10-03 22:51 ` Colin Walters [this message]
2022-10-05 21:29 ` Vivek Goyal
2022-09-28 19:26 ` Vivek Goyal
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=aa26d28d-d352-467c-910c-ab5973a6d759@app.fastmail.com \
--to=walters@verbum.org \
--cc=gmaglione@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=slp@redhat.com \
--cc=stefanha@redhat.com \
--cc=vgoyal@redhat.com \
--cc=virtio-fs@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 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).