Implement policy check for object ownership

[Scott Devoid]

As far as I can tell, there is no policy check for resource ownership.

The current policy checks support: all, none, role-membership, and tenant-membership. This means that the most minimal policy for an action, e.g. "compute:delete" is "role:Name and tenant_id:%(tenant_id)s".
This role would allows any member of a project to delete any instance, which is a problem!

We need something like:
"owns:%(resource_id)" which checks the "user_id" field associated with the resource?

[Andrew Laski (alaski)]

You are correct that there is no 'owns' check, but the policy engine does support checking against arbitrary fields in a 'target'. In a lot(most?) of those checks that occur in the compute/api.py layer, vs the wsgi layer, the target is an instance dict so something like user_id:%(user_id)s would work. Now, that's not universally true so there may be specific checks that could use a more robust target to check against, and I would suggest opening bugs for specific checks in that case. So I marked this as invalid because I think it's a bit general and is somewhat supported. But please open reports for specific policy checks that are too limiting.

If you're interested in expanding the policy engine capabilities to support an owns resource that would fall under a blueprint rather than a bug report.

[Scott Devoid (scott-devoid)]

That's reasonable. A few clarification questions; please forgive me if these are dumb, but I'm new to OS.

1. Where is the separation between 'wsgi' and compute/api.py layers?

2. From what I can tell, to get the "openstack.common.policy.GenericCheck" to have an "ownership" check, we'd need to add "owner_id" to the target and make sure "user_id" was in the credentials? "user_id:%(user_id)s" should always return true since target["user_id"] is the user in the credential?

3. Is there someone who has detailed knowledge of the policy stuff? Looking over the code, I'm going to have trouble landing anything without a lay-of-the-land.

4. Would expansions to the policy engine fall under the oslo project? How are changes to both oslo and nova gated? I can already see that nova.policy calls openstack.common.policy.check but in oslo-incubator that function no longer exists.