[Bug 1880959] Re: Rules from the policy directory files are not reapplied after changes to the primary policy file

[Dmitrii Shcherbakov]

Corey,

The simplest way to test this for a particular version would be to put
the attached test under oslo_policy/tests/test_1880959.py in a checked
out version of oslo.policy and running:

tox -e cover -- oslo_policy.tests.test_1880959.EnforcerTest

It will fail like below without the patch applied and pass if it is.

# ...
testtools.matchers._impl.MismatchError: 'role:fakeA' != 'rule:admin'
Ran 1 tests in 0.005s (+0.001s)
FAILED (id=1, failures=1)

** Attachment added: "test_1880959.py"
   https://bugs.launchpad.net/ubuntu/+source/python-oslo.policy/+bug/1880959/+attachment/5377753/+files/test_1880959.py

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to python-oslo.policy in Ubuntu.
https://bugs.launchpad.net/bugs/1880959

Title:
  Rules from the policy directory files are not reapplied after changes
  to the primary policy file

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive mitaka series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in Ubuntu Cloud Archive rocky series:
  Triaged
Status in Ubuntu Cloud Archive stein series:
  Triaged
Status in Ubuntu Cloud Archive train series:
  Triaged
Status in Ubuntu Cloud Archive ussuri series:
  Triaged
Status in oslo.policy:
  In Progress
Status in python-oslo.policy package in Ubuntu:
  Triaged
Status in python-oslo.policy source package in Xenial:
  Triaged
Status in python-oslo.policy source package in Bionic:
  Triaged
Status in python-oslo.policy source package in Eoan:
  Triaged
Status in python-oslo.policy source package in Groovy:
  Triaged

Bug description:
  [Impact]
  Based on the investigation here https://bugs.launchpad.net/charm-keystone/+bug/1880847 it was determined that rules from policy files located in the directory specified in the policy_dirs option (/etc/<config_dir>/policy.d by default) are not re-applied after the rules from the primary policy file is re-applied due to a change.

  This leads to scenarios where incorrect rule combinations are active.

  Example from the test case in 1880847:

  * policy.json gets read with the following rule;
      "identity:list_credentials": "rule:admin_required or user_id:%(user_id)s",
  * rule.yaml from policy.d is read with the following rule;
  {'identity:list_credentials': '!'}
  * policy.json's mtime gets updated (with or without a content change) and overrides the rule to be
      "identity:list_credentials": "rule:admin_required or user_id:%(user_id)s",
  * rule.yaml doesn't get reapplied since it hasn't changed.

  [Test Case]
  TBD

  [Regression Potential]
  TBD

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1880959/+subscriptions