Comment 0 for bug 1945988

Revision history for this message
Jan Wasilewski (janwasilewski) wrote :

I upgraded OpenStack cloud from rocky to stein and tried to setup new policies as described in release documentation. However I cannot retrieve some information, i.e. command defined in topic.

When executed:
openstack role assignment list --names --system all
output is:
You are not authorized to perform the requested action: identity:list_role_assignments. (HTTP 403) (Request-ID: req-6a27ecd6-7cef-41e4-8470-cf1037f383ac)

That is visible in log print: https://paste.opendev.org/show/809759/

Policy.yaml file is here: https://paste.opendev.org/show/809760/

Warning message is incorrect and says:

2021-10-04 14:20:40.378 1363 WARNING py.warnings [req-6a27ecd6-7cef-41e4-8470-cf1037f383ac f42df418fd404d04b9bdabf2f1b49fd9 509b380257a943b6809c4826e6be372c - default default] /usr/lib/python3/dist-packages/oslo_policy/policy.py:679: UserWarning: Policy "identity:get_mapping":"rule:admin_required" was deprecated in S in favor of "identity:list_mappings":"role:reader and system_scope:all". Reason:

When I removed "identity:get_mapping" from policy file, warning message is like here: https://paste.opendev.org/show/809761/

And when I setup this rule to the value proposed in warning message, I get warning like here: https://paste.opendev.org/show/809762/

So it looks like a problem is looping and doesn't make a sense.

Besides of that it is incorrect that I cannot retrieve output from this command, as my reader user is system all scoped and I should be able to retrieve role assignment list.

I'm trying to get this for user jwasilewski:
openstack role assignment list --names --system all
+--------+---------------------+-------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+---------------------+-------------------+---------+--------+--------+-----------+
| admin | | Adm.Admin@Default | | | all | False |
| reader | jwasilewski@Default | | | | all | False |
+--------+---------------------+-------------------+---------+--------+--------+-----------+

But I'm not sure why 'system_scope': None is defined in logs. Seems it is incorrect behavior.