Description of problem: Users don't have permissions to create VMs to some clusters but they can import VMs to any cluster regardless the permissions. Version-Release number of selected component (if applicable): oVirt Engine Version: 4.1.1.6-1.el7.centos vdsm-4.19.10-1.el7.centos.x86_64 libvirt-client-2.0.0-10.el7_3.5.x86_64 How reproducible: 100% Steps to Reproduce: 1) Setup Datacenter with two clusters: DEV1 and PROD 2) Create a local user - LocalUserA 3) Grant permissions to create VMs in DEV1 cluster: LocalUserA -> [PowerUserRole] -> DEV1 (Cluster) LocalUserA -> [PowerUserRole] -> SAN (Storage) 4) Grant permissions to import/export VMs LocalUserA -> [VmImporterExporter] -> DEV1 (Cluster) LocalUserA -> [VmImporterExporter] -> SAN (Storage) LocalUserA -> [VmImporterExporter] -> SAN-Export (Storage) 5) Confirm that the user can not create VMs in the PROD cluster due to insufficient permissions 6) Login to the Admin Portal and import a VM to the PROD cluster Actual results: VM is imported successfully to the PROD cluster. After the import LocalUserA has no permissions on the imported VM. Can not power on or delete the VM. Expected results: VM import to the PROD cluster fails due to insufficient permissions just like creating new VMs in PROD cluster fails. Additional info:
User can import a VM, but cannot create a VM, because he was given a permission to import VMs, but was not given a permission to create VMs. No bug in this part. After import the user cannot power on or delete the VM - this problem is already solved in bug 1451501. Closing as a duplicate. *** This bug has been marked as a duplicate of bug 1451501 ***
Sorry, I haven't seen that the VM is imported into a different cluster. Looking into this issue.
Currently the import permission is checked only for the Storage Domain and means that the user is able to import VMs from that Storage Domain. Import permission for a cluster have no meaning. In other words, import permission is a permission to import FROM, not a permission to import TO. Proposal to check CREATE_VM permission also, so the user will not be able to import VMs to a cluster where he cannot create VMs seems logical to me. But such a change will break backward compatibility. So the question is whether we need to introduce this additional restriction and whether it needs to be backported to 4.1 (since it is not a regression). Michal, what do you think?
yes, such a change make sense in 4.2
due to capacity, moving to 4.3
Verification builds: ovirt-engine-4.3.0-0.2.master.20181203100035.git0ee44c1.el7 qemu-kvm-ev-2.12.0-18.el7_6.1.1.x86_64 vdsm-4.30.3-71.git7d6039c.el7.x86_64 libvirt-client-4.5.0-10.el7.x86_64 Verification scenario: 1) Setup Datacenter with two clusters: DEV1 and PROD 2) Create a local user - LocalUserA 3) Grant permissions to create VMs in DEV1 cluster: LocalUserA -> [PowerUserRole] -> DEV1 (Cluster) LocalUserA -> [PowerUserRole] -> SAN (Storage) 4) Grant permissions to import/export VMs LocalUserA -> [VmImporterExporter] -> DEV1 (Cluster) LocalUserA -> [VmImporterExporter] -> SAN (Storage) LocalUserA -> [VmImporterExporter] -> SAN-Export (Storage) 5) Confirm that the user can not create VMs in the PROD cluster due to insufficient permissions The next "operation canceled" message appears: "Error while executing action: 1111: User is not authorized to perform this action." 6) Login to the Admin Portal and import a VM to the PROD cluster Verify second import dialog rejects the action with the "operation canceled" message: "Error while executing action: centos44: User is not authorized to perform this action."
This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019. Since the problem described in this bug report should be resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.