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.
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; list_credential s": "rule:admin_ required or user_id: %(user_ id)s", list_credential s': '!'} list_credential s": "rule:admin_ required or user_id: %(user_ id)s",
"identity:
* rule.yaml from policy.d is read with the following rule;
{'identity:
* policy.json's mtime gets updated (with or without a content change) and overrides the rule to be
"identity:
* rule.yaml doesn't get reapplied since it hasn't changed.