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.
_______________________________________________
Virtio-fs mailing list
Virtio-fs@redhat.com
https://listman.redhat.com/mailman/listinfo/virtio-fs
