Has the customer updated to 4.2.6? Can they enable strict user checking?
Hi, Yes, this happens even after enabling strict user checking.
ping?
just wanted to note that in VM Portal the view is correct - user1 sees the VMs allocated by him, and user2 sees his vms.
ok. It means that the Test2 results are correct. It doesn't explain though the 'Actual Result_1:', right? According to this result, user1 sees only one pool vm instead of two vms allocated for him in the response to Get vms API. Please update me if it must be inserted a separate issue or it is related to this bz.
Re-targeting to 4.3.1 since it is missing a patch, an acked blocker flag, or both
(In reply to Polina from comment #29) > ok. It means that the Test2 results are correct. It doesn't explain though > the 'Actual Result_1:', right? According to this result, user1 sees only one > pool vm instead of two vms allocated for him in the response to Get vms API. > Please update me if it must be inserted a separate issue or it is related to > this bz. Pool VMs are not selected deterministically, since it is assumed that any VM in the pool is usable (which is the primary use case of pools) If you run the query repeatedly, do you always get the same VM? If not, I'd suggest that we close CURRENTRELEASE based on the results from comment#26
Hi Ryan, I re-tested in 4.3.3-5 and also in 4.2.8.7-0.1.el7ev .It behaves as expected. GET request with the specific user authorization just gets response as expected. I think it could be a problem with max parameter in the query filter which limited the number of shown VMs (GET https://{{host}}/ovirt-engine/api/vms;max=8?search=SORTBY%20NAME%20ASC authorized for user1). Anyway now could be verified.
Just to clarify, from reading this bug, it seems to be only for Pool VMs and for API calls only. Maybe this should be reflected in the title. Otherwise it is a bit confusing and makes it sound like Spice sessions can be stolen in general.
Doran, this bug is on security component and not attached to any errata. According to comment #34 the issue doesn't reproduce on 4.3.3-5 and also in 4.2.8.7-0.1.el7ev. Can you close this bug?
I think it is on the virt team. Ryan, Polina, do you think this bug shoudl be closed current release?
I'll add to errata, since it's d/s
sync2jira
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/RHEA-2019:3010