deprecation logic fails because of rule names

Bug #2044035 reported by Danny Cocks
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)

Bug Description


I believe the deprecation logic for rules "admin_api" and "admin_or_owner" is faulty. This is because the code in nova/policies/

RULE_ADMIN_OR_OWNER = 'rule:admin_or_owner'

assigns the "name" to be 'rule:admin_or_owner' instead of simply 'admin_or_owner'. This causes the code in the function _handle_deprecated_rule of oslo.policy to fail the following if check, when it is expected to pass:

if ( != and in self.file_rules

In the above check, "file_rules" is a dictionary whose keys are the rule names, for example "admin_or_owner" and not "rule:admin_or_owner".

Steps to reproduce

I created a user with a special role (xyz) to a project and attempted to disable access by adding the override policy of:

"project_owner": "project_id:%(project_id)s and not role:xyz"
"admin_or_owner": "is_admin:True or rule:project_owner"

This appeared to have no effect. By adding extra logging statements to nova/oslo.policy I was able to identify that the deprecation behaviour was not seeing this override.

If I then updated to have:
    DEPRECATED_ADMIN_OR_OWNER_POLICY = policy.DeprecatedRule(
then the policies took effect and my user was correctly refused rights to list servers.

I discovered this using yoga, but I believe this bug is still present on master.


My actual problem is that I want to disable the default deprecation behaviour (which merges "admin_or_owner" into "project_reader_api"). As a temporary workaround I found I could remove this behaviour by explicitly setting the "project_reader_api", etc... rules:

"project_reader_api": "role:reader and project_id:%(project_id)s"
"project_member_api": "role:member and project_id:%(project_id)s"
"project_admin_api": "role:admin and project_id:%(project_id)s"
"project_reader_or_admin": "rule:project_reader_api or rule:context_is_admin"

This causes the logic in oslo.policy to take these rules directly.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.