Red Hat Bugzilla – Bug 1609147
[REST API] all VMs in VM Pool are returned to a pool user regardless of actual VM ownership
Last modified: 2018-09-04 09:42:30 EDT
If VM is taken from a pool by another user it is still listed for all other users with a UserRole permission on the pool. Normally permissions are inherited but VM Pool is a special case, user can have a permission for the pool but that user doesn't own a VM from that pool allocated by another user. This blocks https://github.com/oVirt/ovirt-web-ui/issues/680 in VM Portal. The BackendVmsResource doesn't implement similar logic to the old User Portal's GetAllVmsAndVmPoolsQuery for user API requests.
For verification: Execute GET /api/vms;max=8?search=SORTBY%20NAME%20ASC REST API query. This query is used by ovirt-web-ui to get a list of VMs. Before the fix this query returned a list of all VMs, including pooled VMs. After the fix this query returns a list of all VMs, including only those pooled VMs that are owned by the user.
Why change the behavior of GET /api/vms;max=8?search=SORTBY%20NAME%20ASC? It does what it's supposed to, which is getting all vms sorted by name in ascending order with maximum 8 results with no filtering. Returning only pooled VMs that are owned by the user implies filtering, but the request does not call for filtering, so I think we would actually be creating a bug. If ovirt-web-ui needs a particular subset of VMS (namely all regular VMs plus only user-owned pooled VMs) it should use the API differently, not change the API's behavior. Since we are dealing with VMs, intersecting the results in the API layer would be very costly and so it makes sense to have a designated query. But that query should be activated differently, not by 'hijacking' GET /api/vms;max=8?search=SORTBY%20NAME%20ASC? IMO
(In reply to Ori Liel from comment #2) > Why change the behavior of GET /api/vms;max=8?search=SORTBY%20NAME%20ASC? > > It does what it's supposed to, which is getting all vms sorted by name in > ascending order with maximum 8 results with no filtering. Returning only > pooled VMs that are owned by the user implies filtering, but the request > does not call for filtering, so I think we would actually be creating a bug. > > If ovirt-web-ui needs a particular subset of VMS (namely all regular VMs > plus only user-owned pooled VMs) it should use the API differently, not > change the API's behavior. > > Since we are dealing with VMs, intersecting the results in the API layer > would be very costly and so it makes sense to have a designated query. But > that query should be activated differently, not by 'hijacking' GET > /api/vms;max=8?search=SORTBY%20NAME%20ASC? IMO +1
Ori, please take a look at alternative implementation in https://gerrit.ovirt.org/#/c/93753/
Verified on: ovirt-engine-4.2.6.4-0.0.master.20180821115903.git1327b2f.el7.noarch Steps: 1. Create a new user to the engine. 2. Set UserRole permission(system/cluster) to the user created in step 1. 3. Create a VM Pool with 4 VMs. 4. Allocate a VM from the pool to the user. 5. Check with REST API: GET https://{engine-fqdn}/ovirt-engine/api/vms;max=16?search=SORTBY%20NAME%20ASC Result: The user sees only one VM allocated to him from the pool.
QE verification bot: the bug was verified upstream
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:2623