Policy directory files cannot reset rules and only can update rules.

[Mitya Eremeev]

1. There is no main policy file (policy.yaml or policy.json),
but there are 2 policy files in policy directory:

# ls /etc/octavia/
certs logging.conf octavia.conf policy.d

# ls /etc/octavia/policy.d/
01-default.yaml 02-custom.yaml

# cat /etc/octavia/policy.d/01-default.yaml
load-balancer:member_and_owner: (role:load-balancer_member or role:member) and rule:load-balancer:owner

# cat /etc/octavia/policy.d/02-custom.yaml
os_load-balancer_api:loadbalancer:get_all: '!'
os_load-balancer_api:pool:get_all: '!'

2. An user with member role asks loadbalancer list and gets response:
Unrecognized schema in response body. (HTTP 403)

3. empty file /etc/octavia/policy.d/02-custom.yaml

# cat /etc/octavia/policy.d/02-custom.yaml
{}

4. An user with member role asks loadbalancer list and gets response:
Unrecognized schema in response body. (HTTP 403)

actual behavior:
user was denied to get loadbalancer list

expected behavior:
User got loadbalancer list

[Adam Young (ayoung)]

Would you please distinguish between "reset" and "update" here?

[Adam Young (ayoung)]

"Policy directory rules only can add new rules or
update existing rules in cache, but cannot reset rules
that were set in previous file editions."

I Think this is intentional. Policy and code can be over written by explicit policy files, but allowing the same rule to be definied in multiple files seems to be an exercise in frustration; you need to know the order in which the rules were applied in order to correctly sus what the end rule should be.

WHat is the use case where you would have multiple policy files wioth the same rule? How would you expect the admins tro track the ordering?

[Mitya Eremeev (mitos)]

Sorry for my poor explanation.
The bug is not about adding the same rule in many config files.

I'll give shorter bug description for more clarity:

1. We have default rules which are hard-coded in app, e.g Octavia.
{"a", "default"}

2. Admin does not create custom policy files because he's happy with default policies. He starts app an loaded policy equals rules in app code:
{"a":"default"}

3. Admin wants to adjust policies without app restart.
He creates custom policy file which contains:
{"a": "custom"}

4. Policy was updated correctly.
Loaded policy equals:
{"a": "custom"}

5. Now admin wants to return back to default policies without app restart.
He deletes custom policy file and expects that policy are "reset" to default state if there are not custom policy files.
But loaded policies are still equal:
{"a": "custom"}

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.policy/+/808957
Committed: https://opendev.org/openstack/oslo.policy/commit/949289e094090757576f9251019e10d53af7a663
Submitter: "Zuul (22348)"
Branch: master

commit 949289e094090757576f9251019e10d53af7a663
Author: Mitya_Eremeev <email address hidden>
Date: Tue Sep 14 15:37:31 2021 +0300

    Rules in policy directory files can be deleted.

    Policy directory files can only add new rules or
    update existing rules in cache, but cannot return back
    loaded rules in memory to their default value.
    This incorrect behavior was fixed in the patch.

    Member "_loaded_files" of class Enforcer should keep
    list of loaded policy config files paths.
    In fact if the same file is changed many times
    then the same file path is added many times.
    If a file is deleted it's path not deleted from "_loaded_files".
    The member is very misleading and is not used in code.
    So this member was deleted in the patch because of
    above mentioned resons.

    Change-Id: I9ede38d8cf2ae968d3d8c0b1240bd6a51e6aa931
    Closes-Bug: 1943584

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/oslo.policy/+/814933
Committed: https://opendev.org/openstack/oslo.policy/commit/302643b027a3f3d894c32054cee2220e02a20a8a
Submitter: "Zuul (22348)"
Branch: master

commit 302643b027a3f3d894c32054cee2220e02a20a8a
Author: mitya-eremeev-2 <email address hidden>
Date: Thu Oct 21 14:45:52 2021 +0000

    Don't reset rules without overwriting

    If an user uses Enforcer without overwriting (Enforcer(overwrite=False))
    we should not reset rules and only update loaded rules.
    Enforcer without overwriting is a weird behavior, but it is supported at this moment.
    Maybe it will be eliminated in future because it's misleading.
    Operator cannot conclude what rules are loaded by simply looking in config files.

    Change-Id: I2871407f8c7417a016415ccc166c1f37a9e17908
    Closes-Bug: 1943584

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/oslo.policy 3.10.0 release.