Bug 1920539 - Error screen displayed after user login in admin portal.
Summary: Error screen displayed after user login in admin portal.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.4.3
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ovirt-4.4.5-1
: ---
Assignee: rszwajko
QA Contact: Ivana Saranova
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-01-26 14:19 UTC by Ulhas Surse
Modified: 2022-08-03 12:27 UTC (History)
8 users (show)

Fixed In Version: rhv-4.4.5-10
Doc Type: Bug Fix
Doc Text:
Previously, saving user preferences in the Red Hat Virtualization Manager required the MANIPULATE_USERS permission level. As a result, user preferences were not saved on the server. In this release, the required permission level for saving user preferences was changed to EDIT_PROFILE, which is the permission level assigned by default to all users. As a result, saving user preferences works as expected.
Clone Of:
Environment:
Last Closed: 2021-04-14 11:43:08 UTC
oVirt Team: UX
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2021:1186 0 None None None 2021-04-14 11:43:43 UTC
oVirt gerrit 113128 0 master MERGED core: migrate users.options to user_profiles 2021-03-07 17:36:25 UTC
oVirt gerrit 113859 0 ovirt-engine-4.4.5.z MERGED core: migrate users.options to user_profiles 2021-03-14 07:40:32 UTC

Description Ulhas Surse 2021-01-26 14:19:06 UTC
Description of problem:

- Error screen displayed after user login in admin portal after which the user login works fine. 

- The issue is with local user and as well as external auth users. 


Version-Release number of selected component (if applicable):
RHV 4.4.3

How reproducible:
Always

Steps to Reproduce:
1. Configure a user to login with SuperUser role on a DC.
2. Login with the user
3. It will display the error box which automatically disappears and login works after that. 

Actual results:
Error screen displayed

Expected results:
There should not be any error. 

Additional info:

- Error is not observed if it's configured as system user. 

- Error in engine logs:

~~~
2021-01-26 16:53:25,472+05 INFO  [org.ovirt.engine.core.bll.aaa.UpdateUserOptionsCommand] (default task-43) [eed7f17b-3423-4470-ab4a-ee3feeeb0cea] No permission found for user '99d53be4-76f6-4d23-b7f7-2b57e73f48ba' or one of the groups he is member of, when running action 'UpdateUserOptions', Required permissions are: Action type: 'ADMIN' Action group: 'MANIPULATE_USERS' Object type: 'System'  Object ID: 'aaa00000-0000-0000-0000-123456789aaa'.
2021-01-26 16:53:25,472+05 WARN  [org.ovirt.engine.core.bll.aaa.UpdateUserOptionsCommand] (default task-43) [eed7f17b-3423-4470-ab4a-ee3feeeb0cea] Validation of action 'UpdateUserOptions' failed for user user1@internal-authz. Reasons: USER_NOT_AUTHORIZED_TO_PERFORM_ACTION
~~~

Comment 6 Michal Skrivanek 2021-01-27 05:59:07 UTC
Possibly caused by user options changes from bug 1752751

We shouldn’t assume a user has a System level permission, even though it’s not that common not to add SuperUser just there. 
SuperUser is meant to be just that, a System level all-access account.

Comment 7 Ulhas Surse 2021-01-27 11:02:20 UTC
OK so SuperUser  can access all components agree. https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/sect-system_permissions#Administrator_Roles_Explained
How about DataCenterAdmin role: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/sect-system_permissions#Data_center_permissions_entities

  "For example, a DataCenterAdmin role has administrator privileges only for the assigned data center with the exception of the storage for that data center"


But I can still see the other DataCetners with user assigned to one DC with this role. 
Am I missing any configuration or roles are not working as expected?

Comment 8 Michal Skrivanek 2021-01-27 11:17:32 UTC
None of the roles define visibility. There's only the distinction between user and admin role type. Once you're any kind of admin you can see (as in REST API or webadmin) everything. 
It is not related to this bug

Comment 9 Marina Kalinin 2021-01-27 19:02:42 UTC
(In reply to Michal Skrivanek from comment #8)
> None of the roles define visibility. There's only the distinction between
> user and admin role type. Once you're any kind of admin you can see (as in
> REST API or webadmin) everything. 
> It is not related to this bug

Thanks for clarifying, Michal. So this is by design.

Comment 10 rszwajko 2021-01-29 15:05:42 UTC
MANIPULATE_USERS permission will be no longer required for storing user options after [1] is merged. This should remove the root cause of this problem.

[1] https://gerrit.ovirt.org/113128

Comment 11 Martin Perina 2021-02-01 09:18:02 UTC
Aligning with BZ1171924

Comment 12 Michal Skrivanek 2021-03-04 12:33:56 UTC
that is already in progress, should be in 4.4.6, Radek please keep the bug updated

Comment 13 rszwajko 2021-03-15 09:00:33 UTC
The fix has been backported to 4.4.5.z branch with patch https://gerrit.ovirt.org/c/113859/

Comment 16 Ivana Saranova 2021-04-01 23:36:24 UTC
Steps:
1. Configure a user to login with SuperUser role on a DC.
2. Login with the user

Results:
No error during the login. User is logged in correctly.

Verified in:
ovirt-engine-4.4.5.11-0.1.el8ev.noarch

Comment 23 errata-xmlrpc 2021-04-14 11:43:08 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 (Moderate: RHV Manager (ovirt-engine) 4.4.z [ovirt-4.4.5] 0-day security, bug fix, enhance), 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-2021:1186

Comment 24 meital avital 2022-08-03 12:27:04 UTC
Due to QE capacity, we are not going to cover this issue in our automation


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