Bug 1452361
Summary: | VM import is possible to clusters where permissions to create VMs are not granted | ||
---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Peter Blajev <pblajev> |
Component: | Backend.Core | Assignee: | Shmuel Melamud <smelamud> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Nisim Simsolo <nsimsolo> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 4.1.1.6 | CC: | bugs, michal.skrivanek, nsimsolo, tjelinek |
Target Milestone: | ovirt-4.3.0 | Keywords: | Reopened |
Target Release: | 4.3.0 | Flags: | rule-engine:
ovirt-4.3+
|
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | ovirt-engine-4.3.0_alpha | Doc Type: | If docs needed, set a value |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-02-13 07:46:47 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Peter Blajev
2017-05-18 18:45:40 UTC
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. |