Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-7386

[libvirt] Add support to run virtiofsd inside a user namespace (unprivileged)

    • sst_virtualization_storage
    • ssg_virtualization
    • 30
    • 30
    • 5
    • Dev ack
    • False
    • Hide

      None

      Show
      None
    • None
    • OpenShift Virtualization
    • None
    • Approved Exception
    • 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:

            jtomko@redhat.com Jano Tomko
            rhn-engineering-vgoyal Vivek Goyal
            Nitesh Narayan Lal
            Sebastian Mitterle
            Jano Tomko Jano Tomko
            Lili Zhu Lili Zhu
            Votes:
            0 Vote for this issue
            Watchers:
            30 Start watching this issue

              Created:
              Updated:
              Resolved: