Bug 2040625

Summary: [RFE] Remove the dependency on the QEMU UID/GID (107:107)
Product: Container Native Virtualization (CNV) Reporter: Roman Mohr <rmohr>
Component: VirtualizationAssignee: sgott
Status: CLOSED DEFERRED QA Contact: Kedar Bidarkar <kbidarka>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 4.11.0CC: cnv-qe-bugs
Target Milestone: ---   
Target Release: future   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-02-08 19:59:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 2040272    
Bug Blocks:    

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.