-
Story
-
Resolution: Done-Errata
-
Normal
-
rhel-9.0.0
-
libvirt-10.0.0-6.el9
-
rhel-sst-virtualization-storage
-
ssg_virtualization
-
30
-
30
-
5
-
Dev ack
-
False
-
-
None
-
Red Hat OpenShift Virtualization
-
None
-
Approved Exception
-
Pass
-
Automated
-
If docs needed, set a value
-
-
Unspecified
-
10.0.0
-
None
Description of problem:
virtiofsd (rust) now has the capability to run unprivileged (inside a user namepsace). Next step is to figure out how to integrate this capability in libvirt and where will it make most sense.
Thanks to German who configured and tested and provided instructions on how to run virtiofsd unprivileged.
https://listman.redhat.com/archives/virtio-fs/2021-December/msg00054.html
One big advatange of running virtiofsd as non-root is that system security goes up. One can not drop setuid root binaries on the host and somehow manage to execute these. And there are more examples. So if we can run virtiofsd unprivileged, I think that's a huge win in terms of system security w.r.t virtiofsd.
One limitation of running unprivileged is that one can not create block or char device nodes. That's not allowed.
Hence opening this bug to figure out how this functionality can be integrated in libvirt so that users can enable this unprivileged/rootless mode.
I think if users are running unprivileged VMs, it will make sense to virtiofsd unprivileged. Even in normal case, I think qemu runs as "qemu" user. So it probably will make sense to not run virtiofsd as root and run as "qemu" user instead.
There will probably be few dependencies.
- We need to allocate a range of uid/gid to qemu user.
- We need to select a range dynamically to setup a user namespace. May be a
range of 64K for each virtiofsd instance. If file system is being shared by
multiple VMs, they will have to use same uid/gid range.
- Depending on the use case, shared directory will have to be either chowned
according to uid/gid range of user namespace or one will have to create
idmapped mount mapping. Now basic idmapped mount support is upstream. So
that's not a technology barrier anymore.
Opening this bug to carry out the conversation how libvirt and its users can benefit from this new unpriviliged virtiofsd mode and how to integrate it up the stack so that users can benefit from it.
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
- is blocked by
-
RHEL-15267 Rebase libvirt in RHEL-9.4.0
- Closed
- relates to
-
RHEL-9921 Run virtiofsd unprivileged for CNV
- Closed
- external trackers
- links to
-
RHBA-2023:125049 libvirt bug fix and enhancement update