Bug 1648985

Please add logs, at least the engine.log

what's the version of ovirt-web-ui rpm?
What does the "Run the Pool" mean exactly?

either way, cannot reproduce in current version (1.5.0-0.20181012git7267ba8). But since it's failed in backend it shouldn't be related to ovirt-web-ui version but rather ovirt-engine. That should work in 4.2.6 too

Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both

Sure, Koutuk. That works

sync2jira

sync2jira

The request here seems to be the following:

If a user with a higher permission level is logged into a VM console, a user with a lower permission level who is logged into RHVM should not be allowed to perform management operations (shutdown, poweroff, reboot) until that console is closed.

(In reply to Ryan Barry from comment #27)
> If a user with a higher permission level is logged into a VM console, a user
> with a lower permission level who is logged into RHVM should not be allowed
> to perform management operations (shutdown, poweroff, reboot) until that
> console is closed.

One correction - the user with the lower permission level logged in through VM portal (it is supposed to work for admins that log-in to the webadmin).
QE will try to reproduce it

Tested with:
ovirt-engine-4.4.5.9-0.1.el8ev.noarch

Steps:
1. Create two users, test1 and test2.
2. Create vm pool:
Pool Name: mypool
Number of VMs: 1
Prestarted VMs: 1
Pool Type: Automatic
Stateful Pool: uncheck
VM name: mypool-1
3. Add users with permissions:
- add user test1 with permission SuperUser on Data Center
- add user test2 with permission UserRole on Pool mypool
4. Log in to VM Portal with user test1, and open console of VM mypool-1
5. Log in to VM Portal with user test2 on another browser:
- click Take a Virtual Machine
- go to VM mypool-1 detail page
- click Reboot
- click Shutdown


Results:
1. The VM mypool-1 was rebooted successfully by user test2.
2. The VM mypool-1 was shut down successfully by user test2.
3. User test1 lost VM console. 

engine=# select log_time, correlation_id, message from audit_log where message like '%mypool-1%' order by log_time desc;
select log_time, correlation_id, message from audit_log where message like '%mypool-1%' order by log_time desc;
          log_time          |            correlation_id            |                                           message                                            
----------------------------+--------------------------------------+----------------------------------------------------------------------------------------------
 2021-03-22 17:30:45.839+02 |                                      | VM mypool-1 is down. Exit message: Admin shut down from the engine
 2021-03-22 17:30:43.064+02 | 63f9f69b-c108-4beb-8737-4db0d04507f6 | VM shutdown initiated by test2@internal-authz on VM mypool-1 (Host: host_mixed_2).
 2021-03-22 17:28:50.571+02 | bb6a1a02-5bc5-41f5-ab55-4bd06f3d3218 | VM mypool-1 is rebooting. Rebooted by: test2@internal-authz
 2021-03-22 17:27:59.273+02 | 518f7051-05a6-404e-b1d4-deebe566faea | User test2 successfully attached to VM mypool-1 in VM Pool mypool.
 2021-03-22 17:27:57.329+02 | 518f7051-05a6-404e-b1d4-deebe566faea | Attaching User test2 to VM mypool-1 in VM Pool mypool was initiated by test2@internal-authz.
 2021-03-22 17:27:42.055+02 |                                      | User test1@internal-authz is connected to VM mypool-1.
 2021-03-22 17:26:38.429+02 | 37b90fc1                             | User test1@internal-authz initiated console session for VM mypool-1
 2021-03-22 17:25:28.051+02 | 35ff0807                             | VM mypool-1 was restarted on Host host_mixed_2 as stateless
 2021-03-22 17:24:51.284+02 | 35ff0807                             | Starting VM mypool-1 as stateless was initiated.
 2021-03-22 17:24:26.51+02  | 47f8a59f-a327-48b6-b65e-fedadd287cdd | VM mypool-1 creation has been completed.
 2021-03-22 17:24:10.954+02 | 47f8a59f-a327-48b6-b65e-fedadd287cdd | VM mypool-1 creation was initiated by admin@internal-authz.

Seems this should have been fixed by bz 1609147.
Sharon, is there a chance that the vm portal no longer initiates a query that is filtered + limited + sorted when listing the vms?

Note that the problem here is not that the user with SuperUser role sees the VM assigned to the user with UserRole but the other way around.

It seems to me that the fix to bz 1609147 was supposed to solve this - do you know or can you easily tell if the query that the VM portal initiates reaches [1]? I don't have the VM portal deployed to check so your feedback on this would be appreciated.

[1] https://github.com/oVirt/ovirt-engine/blob/ovirt-engine-4.4.6.2/backend/manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/resource/BackendVmsResource.java#L108

(In reply to Arik from comment #34)
> Note that the problem here is not that the user with SuperUser role sees the
> VM assigned to the user with UserRole but the other way around.


The problem here is that the pool VM was assigned and taken from the pool only by the user with UserRole permission (based on the description above, the user with UserRole does "click Take a Virtual Machine").
So the user with UserRole is the one that is assigned with this VM. 
The user with SuperUser role has inheritance permissions to view/open console to this VM, but he is not assigned to the VM via the Pool assignment directly. 

Permissions inheritance and pool assignments permissions are mixed and the result is that both users have permissions to the same VM. 

But even from a functional prespective, prestarted VMs doesn't mean that those VMs are auto assigned to all admin/Superuser users. They are still marked as non-attaced and that's why any user with UserRole permission can take this VM.

For solving this we need to add a new logic that in case a admin user opens a console to a pool VM, he automatically marked as assigned to this VM and the VM is taken out of the pool. AFAIK this is not the current behaviour.


> 
> It seems to me that the fix to bz 1609147 was supposed to solve this - do
> you know or can you easily tell if the query that the VM portal initiates
> reaches [1]? I don't have the VM portal deployed to check so your feedback
> on this would be appreciated.
> 
> [1]
> https://github.com/oVirt/ovirt-engine/blob/ovirt-engine-4.4.6.2/backend/
> manager/modules/restapi/jaxrs/src/main/java/org/ovirt/engine/api/restapi/
> resource/BackendVmsResource.java#L108

The code is reached and that's why the UserRole user can't view this pool vm until he "click Take a Virtual Machine". 
the filter works ok based on what I wrote previously.

Ack, thanks Sharon.
So seems that we just need to consider VMs that there's a console connected to them as ineligible for assignment in order to fix this

It's possible to check whether a console is connected looking at "clientIp" item in VM stats. It's either empty or it contains the IP address of the connected client.

A drawback is that if Vdsm restarts while a client is connected, "clientIp" gets cleared despite the console is still open. AFAIK we cannot reconstruct the information on Vdsm recovery because we get only one-time notifications from libvirt on console connection and disconnection. A workaround would be to check "elapsedTime" (Vdsm running time) in the host stats when clientIp is detected as empty. Then we might not be sure about console disconnection and the admin had to connect and disconnect again to free up the console for other users. Which is probably still better than giving them the extra permission in such a situation.

The handling of VDSM recovery can be done in several ways, we thought of either:
1. keep reporting the previous client ip
2. add another field
based on information that is stored in the metadata

But maybe we can consider it a rare flow and start with consuming the client ip the way it is reported now, and see if we actually need to have better treatment of VDSM restarting while the console it open

Verified with:
ovirt-engine-4.5.0.2-0.7.el8ev.noarch

Steps:
1. Create two users, test1 and test2.
2. Create vm pool:
Pool Name: mypool
Number of VMs: 1
Prestarted VMs: 1
Pool Type: Automatic
Stateful Pool: uncheck
VM name: mypool-1
3. Add users with permissions:
- add user test1 with permission SuperUser on System
- add user test2 with permission UserRole on Pool mypool
4. Log in to VM Portal with user test1, and open console of VM mypool-1
5. Log in to VM Portal with user test2 on another browser, try to Take a Virtual Machine

Results:
User test2 can't take the VM from pool when the VM console is opened by user test1, there is an error message saying:
"START_POOL failed [Cannot attach user to VM. Another user is connected via console to the VM., Cannot allocate and run VM from VM-Pool. There are no available VMs in the VM-Pool.]"

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 (Moderate: RHV Manager (ovirt-engine) [ovirt-4.5.0] security update), 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/RHSA-2022:4711