yahoo-eng-team team mailing list archive

[Danny Cocks <2044035@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Description
===========

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

RULE_ADMIN_OR_OWNER = 'rule:admin_or_owner'
...
DEPRECATED_ADMIN_OR_OWNER_POLICY = policy.DeprecatedRule(
    name=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 (
    deprecated_rule.name != default.name and
    deprecated_rule.name 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 base.py to have:
    DEPRECATED_ADMIN_OR_OWNER_POLICY = policy.DeprecatedRule(
        name=RULE_ADMIN_OR_OWNER[len("rule:"):],
    ...
    )
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.


Workaround
==========

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.

** Affects: nova
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/2044035

Title:
  deprecation logic fails because of rule names

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===========

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

  RULE_ADMIN_OR_OWNER = 'rule:admin_or_owner'
  ...
  DEPRECATED_ADMIN_OR_OWNER_POLICY = policy.DeprecatedRule(
      name=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 (
      deprecated_rule.name != default.name and
      deprecated_rule.name 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 base.py to have:
      DEPRECATED_ADMIN_OR_OWNER_POLICY = policy.DeprecatedRule(
          name=RULE_ADMIN_OR_OWNER[len("rule:"):],
      ...
      )
  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.

  
  Workaround
  ==========

  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 manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/2044035/+subscriptions