Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1609147

Summary:	[REST API] all VMs in VM Pool are returned to a pool user regardless of actual VM ownership
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Michal Skrivanek <michal.skrivanek>
Component:	ovirt-engine	Assignee:	Arik <ahadas>
Status:	CLOSED ERRATA	QA Contact:	Liran Rotenberg <lrotenbe>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.2.4	CC:	ahadas, bugs, cminkema, dfediuck, eheftman, gshereme, gveitmic, lrotenbe, lsurette, mkalinin, oliel, ratamir, Rhev-m-bugs, smelamud, srevivo, tburke
Target Milestone:	ovirt-4.2.6	Keywords:	ZStream
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-09-04 13:41:42 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:
Bug Depends On:
Bug Blocks:	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