Bug 1609147 - [REST API] all VMs in VM Pool are returned to a pool user regardless of actual VM ownership
Summary: [REST API] all VMs in VM Pool are returned to a pool user regardless of actua...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.2.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-4.2.6
: ---
Assignee: Arik
QA Contact: Liran Rotenberg
URL:
Whiteboard:
Depends On:
Blocks: 1608093
TreeView+ depends on / blocked
 
Reported: 2018-07-27 06:50 UTC by Michal Skrivanek
Modified: 2021-12-10 16:56 UTC (History)
16 users (show)

Fixed In Version: ovirt-engine-4.2.6.4
Doc Type: Bug Fix
Doc Text:
Previously, users were able to see all the virtual machines in a pool, rather than only those virtual machines to which they are assigned. In this release, users will only see the virtual machines to which they are assigned.
Clone Of:
Environment:
Last Closed: 2018-09-04 13:41:42 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github oVirt ovirt-web-ui issues 680 0 None closed all VMs in VM Pool are listed regardless of actual VM ownership 2020-05-29 12:46:21 UTC
Red Hat Bugzilla 1597649 0 high CLOSED VM Portal - all VMs from VM Pool + VM Pool itself are displayed for a brand new VM Pool 2023-10-06 17:50:27 UTC
Red Hat Bugzilla 1608093 0 medium CLOSED VM Portal white screen within a few seconds of initial render 2021-12-10 16:55:26 UTC
Red Hat Issue Tracker RHV-44237 0 None None None 2021-12-10 16:56:45 UTC
Red Hat Product Errata RHBA-2018:2623 0 None None None 2018-09-04 13:42:30 UTC
oVirt gerrit 93586 0 master ABANDONED restapi: VM list for ovirt-web-ui 2020-05-29 12:46:22 UTC
oVirt gerrit 93753 0 master MERGED core: filter unattached vms from pools for vm portal 2020-05-29 12:46:22 UTC
oVirt gerrit 93785 0 ovirt-engine-4.2 MERGED core: filter unattached vms from pools for vm portal 2020-05-29 12:46:22 UTC

Internal Links: 1597649 1608093

Description Michal Skrivanek 2018-07-27 06:50:32 UTC
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.

Comment 1 Shmuel Melamud 2018-08-08 15:42:12 UTC
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.

Comment 2 Ori Liel 2018-08-13 07:23:49 UTC
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

Comment 3 Arik 2018-08-14 14:58:49 UTC
(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

Comment 4 Michal Skrivanek 2018-08-15 09:30:27 UTC
Ori, please take a look at alternative implementation in https://gerrit.ovirt.org/#/c/93753/

Comment 5 Liran Rotenberg 2018-08-23 08:16:26 UTC
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.

Comment 8 Raz Tamir 2018-08-28 19:30:41 UTC
QE verification bot: the bug was verified upstream

Comment 10 errata-xmlrpc 2018-09-04 13:41:42 UTC
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


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