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

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

Just tested the scenario with 4.4 and it is working 
Will check that for latest 4.3

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

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.

(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 ...

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'

*** Bug 1852778 has been marked as a duplicate of this bug. ***

(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

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 ....

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.

Verified on ovirt-engine-4.4.3.3-0.19.el8ev.noarch

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.

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

(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