Bug 2040625 - [RFE] Remove the dependency on the QEMU UID/GID (107:107)
Summary: [RFE] Remove the dependency on the QEMU UID/GID (107:107)
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Virtualization
Version: 4.11.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: future
Assignee: sgott
QA Contact: Kedar Bidarkar
URL:
Whiteboard:
Depends On: 2040272
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-01-14 10:08 UTC by Roman Mohr
Modified: 2022-02-08 19:59 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-02-08 19:59:57 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Roman Mohr 2022-01-14 10:08:10 UTC
Description of problem:


Right now we have some distributed places which can work together well because they all assume that the qemu user has UID 107 and GID 107:

 * ContainerDisks are needed to be either eadable to everyone or they need UID/GID 107 with read permissions.
 * The same applies to PVCs
 * The same applies to hotplug

virt-handler does for the above cases privileged operations across different namespaces where it has to assume that the UID/GID is the same in all containers involved.

This assumption can break apart when:

 * PVCs don't have the right permission
 * ContainerDisks are not created with the right permissions
 * Hotplug PVCs don't have the right permissions
 * (potentially, not sure yet): User namespaces will be used?

Potential issues:

 * changing file permissions in the case of containerdisks can lead to a full copy of the file (depending on the CRI configuration)
 * If we want to e.g. drop the SCC capability to set our own UIDs/GIDs on VM containers, random qemu PIDs/GIDs can lead to permission issues
 * With user-namespaces, changing permissions may cause issues
Version-Release number of selected component (if applicable):


How reproducible:

 * Create a containerdisk which can't be read by user 107, the VM will not start.

Steps to Reproduce:
1.
2.
3.

Actual results:


 * Users have to be very careful regarding to permissions on ContainerDisks
 * Our VM pods need to be created in the context of elevated privileges on a SCC, so that we can freely set the qemu UID on the pod when using non-root mode (so we can do better here, non-root already means that we don't have to set UID 0).


Expected results:


 * Users don't have to care about the permissions in the containerdisk, since they have obviously have the permission to pull a containerdisk, there is no reasonable case where we would want to deny them access to the disk.
 * That we don't have to care about user-namespaces in the context of the VM-Pod
 * That we don't have to care about the actual qemu UID.

Finally KubeVirt can work with the arbitrary UID assigning mechanism of OpenShift.

Additional info:


One way to resolve all these issues, is getting rid of the need to mount containerdisks and PVCs to the mount namespace of qemu. Passing file-descriptors which are opened by virt-handler to qemu can solve this.

Likewise for PVCs which are directly attached, passing file descriptors can help getting rid of the need to change permissions on the files and block devices, avoiding possible trouble with user-namespaces.


Note You need to log in before you can comment on or make changes to this bug.