Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be available on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1808320 - [Permissions] DataCenterAdmin role defined on DC level does not allow Cluster creation
Summary: [Permissions] DataCenterAdmin role defined on DC level does not allow Cluster...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.3.8
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-4.4.3
: 4.4.3
Assignee: Eli Mesika
QA Contact: Petr Matyáš
URL:
Whiteboard:
: 1852778 (view as bug list)
Depends On:
Blocks: 1881958
TreeView+ depends on / blocked
 
Reported: 2020-02-28 09:21 UTC by Steffen Froemer
Modified: 2020-11-29 07:44 UTC (History)
8 users (show)

Fixed In Version: rhv-4.4.3-3
Doc Type: Bug Fix
Doc Text:
Previously, users with specific Data Center or Cluster permissions could not edit the cluster they have access to. In this release, users with specific Data Center or Cluster permissions can edit the cluster they have access to if they don't change the MAC pool associated with the cluster or attempt to add a new MAC pool.
Clone Of:
Environment:
Last Closed: 2020-11-24 13:09:21 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1428754 0 high CLOSED User with create_cluster permit on DC cannot create cluster 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1863051 0 unspecified CLOSED [RFE] Allow management of permissions of MAC Address Pools via REST-API 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2020:5179 0 None None None 2020-11-24 13:09:46 UTC
oVirt gerrit 110273 0 master MERGED core: enable specific DC admin to create clusters 2020-11-27 15:42:25 UTC
oVirt gerrit 111497 0 master MERGED db: fixing MAC POOL user role type 2020-11-27 15:42:26 UTC

Internal Links: 1863051

Description Steffen Froemer 2020-02-28 09:21:30 UTC
Description of problem:
When assign DataCenterAdmin role to a user for a specific Datacenter, this user is not allowed to create a cluster in this DC

Version-Release number of selected component (if applicable):
ovirt-engine-4.3.8.2-0.4.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. Create local user 'test' 
   # ovirt-aaa-jdbc-tool user add test
2. Create a Datacenter "DUMMY", using SuperUser (e.g. admin@internal)
3. Select DataCenter "DUMMY" and add 'DataCenterAdmin' role for user 'test@internal' in Permissions section
4. Login with user 'test' into admin portal
5. Create a new Cluster 'dummy-cluster' within DC 'DUMMY'

Actual results:
2020-02-28 08:55:10,517Z INFO  [org.ovirt.engine.core.bll.AddClusterCommand] (default task-118) [ea628bc5-20b2-4413-a49c-cea2a1329404] No permission found for user 'b15b3547-c501-4ee8-94fc-ef680d5c514a' or one of the groups he is member of, when running action 'AddCluster', Required permissions are: Action type: 'ADMIN' Action group: 'CONFIGURE_MAC_POOL' Object type: 'MAC Pool'  Object ID: '58ca604b-017d-0374-0220-00000000014e'.                                                                                                                                                                    
2020-02-28 08:55:10,517Z WARN  [org.ovirt.engine.core.bll.AddClusterCommand] (default task-118) [ea628bc5-20b2-4413-a49c-cea2a1329404] Validation of action 'AddCluster' failed for user test@internal-authz. Reasons: VAR__TYPE__CLUSTER,VAR__ACTION__CREATE,USER_NOT_AUTHORIZED_TO_PERFORM_ACTION   
2020-02-28 08:56:04,642Z INFO  [org.ovirt.engine.core.bll.AddPermissionCommand] (EE-ManagedThreadFactory-engine-Thread-163374) [7de72136-c3ea-45e2-8733-b690394aafe2] Running command: AddPermissionCommand internal: false. Entities affected :  ID: c665b7c4-411e-40b0-b231-0ed1d8279235 Type: StoragePoolAction group MANIPULATE_PERMISSIONS with role type USER,  ID: c665b7c4-411e-40b0-b231-0ed1d8279235 Type: StoragePoolAction group ADD_USERS_AND_GROUPS_FROM_DIRECTORY with role type USER 

Expected results:
The user should be allowed to create cluster within the DC he has DataCenterAdmin permissions for.

Additional info:
Adding 'MacPoolUser' role permission on System-level does workaround the issue. 
Although, permitting DataCenterAdmin roles on Systems permission level, a user can add DC and Clusters without any issues

Comment 1 Eli Mesika 2020-06-18 19:25:02 UTC
Looking on the DataCenterAdmin creation role in DB I see 

engine=# select * from roles where name = 'DataCenterAdmin';
-[ RECORD 1 ]-----------+-----------------------------------------------------------------------------------------------------
id                      | def00002-0000-0000-0000-def000000002
name                    | DataCenterAdmin
description             | Administrator Role, permission for all the objects underneath a specific Data Center, except Storage
is_readonly             | t
role_type               | 1
allows_viewing_children | t
app_mode                | 1

 

As you can see the 'is_readonly' flag is set to 'true' , meaning , this role can see all objects below the DC but in order to create a cluster you will need to set for this user the ClusterAdmin as well.

Looking in ClusterAdmin, I can see the same behavior :

# select * from roles where name = 'ClusterAdmin';
-[ RECORD 1 ]-----------+---------------------------------------------------------------------------------
id                      | def00001-0000-0000-0000-def000000001
name                    | ClusterAdmin
description             | Administrator Role, permission for all the objects underneath a specific Cluster
is_readonly             | t
role_type               | 1
allows_viewing_children | t
app_mode                | 255

Here also 'is_readonly' is true 


So, IMO , it's simply working as designed

Please consider closing the bug with 'NOTABUG' if you agree with that.

In case you think this is misleading and the default should be with 'is_readonly' set to 'false' , please file a RFE for that

Comment 2 Steffen Froemer 2020-06-22 07:17:46 UTC
Based on documentation [1] the DataCenterAdmin "Possesses administrative permissions for all objects underneath a specific data center except for storage." 
This means, the DC-Admin can do everything within his DC, except managing storage. Why should I than require ClusterAdmin rights additionally? This totally does not make any sense. All means all and not all, except new Clusters.

I have all administration permission to the Clusters beneath my DC, but I'm not able to create new ones.

That said, this isn't a RFE in my eyes. It needs to be fixed!


[1]: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.3/html/administration_guide/sect-system_permissions#Administrator_Roles_Explained

Comment 3 Eli Mesika 2020-06-23 13:13:00 UTC
Just tested the scenario with 4.4 and it is working 
Will check that for latest 4.3

Comment 4 Eli Mesika 2020-06-28 09:41:12 UTC
Tested on latest 4.3 (ovirt-engine-4.3.10.4-1.el7.noarch) 
Scenario is working for me , please re test :

1) logging as admin
2) add DC "dummy"
3) create a user and assign a password to it 

/usr/bin/ovirt-aaa-jdbc-tool user add test
/usr/bin/ovirt-aaa-jdbc-tool user password-reset test --password=pass:password --password-valid-to="2025-08-15 10:30:00Z"

4) add test user to users and assign it DatacenterAdmin role 
5) logout
6) login with test user 
7) try to create a dummy cluster under dummy DC

Comment 5 Steffen Froemer 2020-06-30 08:29:41 UTC
Where do I get the version you've tested on?
I upgraded my RHV to latest available (ovirt-engine-4.3.10.4-0.1.el7.noarch) and the issue still exist.

Comment 6 Martin Perina 2020-06-30 08:48:46 UTC
(In reply to Steffen Froemer from comment #5)
> Where do I get the version you've tested on?
> I upgraded my RHV to latest available (ovirt-engine-4.3.10.4-0.1.el7.noarch)
> and the issue still exist.

Eli tested on upstream oVirt version (which is much easier for developers to use) while you are using downstream RHV release. But from feature perspective those versions should be the same, so the problem is either environment specific or there are some differences in reproducing steps.

Steffen, could you please take a look at reproducing steps from Eli in Comment 4 and try them on your setup? If those steps work, then we need to find out what's the difference in your original reproducing steps ...

Comment 7 Steffen Froemer 2020-06-30 09:02:32 UTC
Martin, got it working now.

There is a single difference in the use-case I have in mind and the test-case Eli is covering.

It works using "DC Admin role" on system level, but not working, when I create the DC by admin first and setup the permissions on the DC level.


This works:

1. Create local user 'test' 
   
/usr/bin/ovirt-aaa-jdbc-tool user add test
/usr/bin/ovirt-aaa-jdbc-tool user password-reset test --password=pass:password --password-valid-to="2025-08-15 10:30:00Z"

2. add test user to users and assign it DatacenterAdmin role 
3. Create a Datacenter "DUMMY", using SuperUser (e.g. admin@internal)

4. Login with user 'test' into admin portal
5. Create a new Cluster 'dummy-cluster' within DC 'DUMMY'


This fails, but expected to work, as a DC-Admin on Systemlevel would have access to all DC in RHV, except a single, specific one.

1. Create local user 'test' 
   # ovirt-aaa-jdbc-tool user add test
2. Create a Datacenter "DUMMY", using SuperUser (e.g. admin@internal)
3. Select DataCenter "DUMMY" and add 'DataCenterAdmin' role for user 'test@internal' in Permissions section
4. Login with user 'test' into admin portal
5. Create a new Cluster 'dummy-cluster' within DC 'DUMMY'

Comment 8 Martin Perina 2020-07-01 10:16:07 UTC
*** Bug 1852778 has been marked as a duplicate of this bug. ***

Comment 11 Eli Mesika 2020-07-02 00:01:38 UTC
(In reply to Steffen Froemer from comment #7)
> Martin, got it working now.
> 
> There is a single difference in the use-case I have in mind and the
> test-case Eli is covering.
> 
> It works using "DC Admin role" on system level, but not working, when I
> create the DC by admin first and setup the permissions on the DC level.
> 
> 
> This works:
> 
> 1. Create local user 'test' 
>    
> /usr/bin/ovirt-aaa-jdbc-tool user add test
> /usr/bin/ovirt-aaa-jdbc-tool user password-reset test
> --password=pass:password --password-valid-to="2025-08-15 10:30:00Z"
> 
> 2. add test user to users and assign it DatacenterAdmin role 
> 3. Create a Datacenter "DUMMY", using SuperUser (e.g. admin@internal)
> 
> 4. Login with user 'test' into admin portal
> 5. Create a new Cluster 'dummy-cluster' within DC 'DUMMY'
> 
> 
> This fails, but expected to work, as a DC-Admin on Systemlevel would have
> access to all DC in RHV, except a single, specific one.
> 
> 1. Create local user 'test' 
>    # ovirt-aaa-jdbc-tool user add test
> 2. Create a Datacenter "DUMMY", using SuperUser (e.g. admin@internal)
> 3. Select DataCenter "DUMMY" and add 'DataCenterAdmin' role for user
> 'test@internal' in Permissions section
> 4. Login with user 'test' into admin portal
> 5. Create a new Cluster 'dummy-cluster' within DC 'DUMMY'


OK , here is the explanation (this is true for each hierarchical permission like dc->cluster->host etc)

When you set a DatacenterAdmin role for a user from Adminitration-->Configure-->System Permissions then the permission is hierarchical and is not specific for a certain object 
When you set a DatacenterAdmin role by selecting a specific DC and assigning from the permission tab a user DatacenterAdmin role, then  the permission is not hierarchical and is specific for a certain object


For example :

You have DC1 and DC2 , under DC1 you have Cluster1 and under DC2 you have Cluster2 

Now you add user1 as a  DatacenterAdmin role for a user from Adminitration-->Configure-->System Permissions
And user2 by selecting DC1 and assigning from the permission tab a user DatacenterAdmin role

When you login with user1 , it can access DC1 and DC2 and also Cluster1 and Cluster2 and create objects inside DC1 and DC2 
but when login with user2 ,  it can access DC1 only , it will not able to create objects under DC1 and can not access DC2 at all 

when looking in the permissions table in DB you see for user1 :

id             | f5e6ea16-ee6a-4d2f-9175-f8599095cb96
role_id        | def00002-0000-0000-0000-def000000002
ad_element_id  | 697efdd5-a863-4638-a2c0-8fcc1e01933e
object_id      | aaa00000-0000-0000-0000-123456789aaa
object_type_id | 1
creation_date  | 1593643551

and for user2:

id             | a62946a2-5103-4685-8e9e-31d15d1a13bd
role_id        | def00002-0000-0000-0000-def000000002
ad_element_id  | c5a84ac3-3ba5-4f3b-be32-1a217c81cb43
object_id      | f02642ea-e324-46c6-b3ce-a3cdb1b5e786
object_type_id | 14
creation_date  | 1593644141


Notice that user1 got object_type_id = 1 and object_id = aaa00000-0000-0000-0000-123456789aaa which means system level permissions (on root object aaa00000-0000-0000-0000-123456789aaa)  on anything under this object (in that case - DC)
If you look at user2 you see that it get only object_type_id = 14 which means DC only on object_id = f02642ea-e324-46c6-b3ce-a3cdb1b5e786 (DC1)

So, the permissions system works as follows:

either give a general permission , not on a specific object and that will be propagated to all objects and their children
or , give a specific permission and handle all the permission tree manually while children are excluded by default 

Martin, to me that make sense , changing that for specific object permissions is not easy , you will have to insert all the hierarchical permissions tree manually, more than that , when objects under the root object (DC for example in that case) are added/deleted/moved , you will have to reflect those changes in the permissions table and this will be error prone and complex.

I think that this should be closed as NOTABUG , apart from that I think that documentation should cover the explanation I gave above clearly so admins will be aware for the difference of global permission vs. specific permission

Comment 12 Eli Mesika 2020-07-02 06:05:49 UTC
I must say that new UI introduced in 4.3 IIRC that removed the hierarchical tree panel from the UI makes it pretty difficult to add permissions per object.
When you had the  hierarchical tree panel, you could set the permissions visually and correctly, now, you have to remember the hierarchy of objects which makes this task not trivial ....

Comment 22 RHEL Program Management 2020-07-30 07:47:49 UTC
The documentation text flag should only be set after 'doc text' field is provided. Please provide the documentation text and set the flag to '?' again.

Comment 24 Petr Matyáš 2020-09-22 14:44:34 UTC
Verified on ovirt-engine-4.4.3.3-0.19.el8ev.noarch

Comment 26 Eli Marcus 2020-11-22 17:25:05 UTC
Hi Eli, 
please review this doc text for the errata: 

Previously, users with specific Data Center or Cluster permissions could not edit the cluster they have access to.
In this release, users with specific Data Center or Cluster permissions can edit the cluster they have access to if they don't change the MAC pool associated with the cluster or attempt to add a new MAC pool.

Comment 30 errata-xmlrpc 2020-11-24 13:09:21 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 (Low: Red Hat Virtualization security, bug fix, and enhancement 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-2020:5179

Comment 31 Eli Mesika 2020-11-29 07:44:14 UTC
(In reply to Eli Marcus from comment #26)
> Hi Eli, 
> please review this doc text for the errata: 
> 
> Previously, users with specific Data Center or Cluster permissions could not
> edit the cluster they have access to.
> In this release, users with specific Data Center or Cluster permissions can
> edit the cluster they have access to if they don't change the MAC pool
> associated with the cluster or attempt to add a new MAC pool.

approved


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