Comment 0 for bug 1869273

Revision history for this message
Andrew Bogott (andrewbogott) wrote :

I have a simple, permissive keystone rule in my policy.yaml:

"identity:list_projects": ""

That should allow any token to list projects. It does, but I'm also scolded:

> UserWarning: Policy identity:list_projects failed scope check. The token used to make the
> request was project scoped but the policy requires ['system'] scope. This behavior may
> change in the future where using the intended scope is required

I see that enforce() starts by loading my custom rule:

  to_check = self.rules[rule]

And at the bottom, to_check is passed to _check(). So that's all good.

Before calling _check(), it checks my token scope. But it doesn't check my token against the custom rule to_check, instead it checks it against a different rule, loaded from registered_rules().

So it checks my scope against policy-in-code but then calls _check() against the policy-in-file.

I'm open to the idea that this is somehow good or necessary, but it surprises me! I'm overriding the policy; shouldn't it always use the rule that I gave it? Am I misunderstanding what the scope check is for?

Tested in Queens, but I've verified that the registered_rules() check is also present in the git head of oslo.policy.