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

[Corey Bryant]

Thanks Dmitrii, we'll need to get this backported as far as we can
upstream once the fix lands in master. I'll target the rest of the
ubuntu and cloud archive releases. Would you be able to add some simple
repro steps to the [Test Case] section in the bug description? This can
include a juju based deploy. That will help us verify SRU fixes for each
release combination once we have fixes in corresponding -proposed
pockets available for testing.

** Description changed:

- 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.
+ [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",
+     "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",
+     "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

** Also affects: python-oslo.policy (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: python-oslo.policy (Ubuntu Eoan)
   Importance: Undecided
       Status: New

** Also affects: python-oslo.policy (Ubuntu Bionic)
   Importance: Undecided
       Status: New

** Changed in: python-oslo.policy (Ubuntu Xenial)
       Status: New => Triaged

** Changed in: python-oslo.policy (Ubuntu Bionic)
       Status: New => Triaged

** Changed in: python-oslo.policy (Ubuntu Eoan)
       Status: New => Triaged

** Changed in: python-oslo.policy (Ubuntu Eoan)
   Importance: Undecided => High

** Changed in: python-oslo.policy (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: python-oslo.policy (Ubuntu Xenial)
   Importance: Undecided => High

** Also affects: cloud-archive
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/ussuri
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/queens
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/train
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/stein
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/mitaka
   Importance: Undecided
       Status: New

** Also affects: cloud-archive/rocky
   Importance: Undecided
       Status: New

** Changed in: cloud-archive/mitaka
   Importance: Undecided => High

** Changed in: cloud-archive/mitaka
       Status: New => Triaged

** Changed in: cloud-archive/queens
   Importance: Undecided => High

** Changed in: cloud-archive/queens
       Status: New => Triaged

** Changed in: cloud-archive/rocky
   Importance: Undecided => High

** Changed in: cloud-archive/rocky
       Status: New => Triaged

** Changed in: cloud-archive/stein
   Importance: Undecided => High

** Changed in: cloud-archive/stein
       Status: New => Triaged

** Changed in: cloud-archive/train
   Importance: Undecided => High

** Changed in: cloud-archive/train
       Status: New => Triaged

** Changed in: cloud-archive/ussuri
   Importance: Undecided => High

** Changed in: cloud-archive/ussuri
       Status: New => Triaged

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