Open Stack

Hey all,

Recently, we had a customer try the following command as a non-admin 
with a policy role granted in policy.json to allow live migrate:

   "os_compute_api:os-migrate-server:migrate_live": "rule:admin_api or 
role:Operator"

The scenario is that they have a server in project A and a user in 
project B with role:Operator and the user makes a call to live migrate 
the server.

But when they call the API, they get the following error response:

   {"itemNotFound": {"message": "Instance <uuid server 1> could not be 
found.", "code": 404}}

A superficial look through the code shows that the live migrate should 
work, because we have appropriate policy checks in the API, and the 
request makes it past those checks because the policy.json has been set 
correctly.

A common pattern in our APIs is that we first compute_api.get() the 
instance object and then we call the server action (live migrate, stop, 
start, etc) with it after we retrieve it. In this scenario, the 
compute_api.get() fails with NotFound.

And the reason it fails with NotFound is because, much lower level, at 
the DB layer, we have a keyword arg called 'project_only' which, when 
True, will scope a database query to the RequestContext.project_id only. 
We have hard-coded 'project_only=True' for the instance get query.

So, when the user in project B with role:Operator tries to retrieve the 
instance record in project A, with appropriate policy rules set, it will 
fail because 'project_only=True' and the request context is project B, 
while the instance is in project A.

My question is: can we get rid of the hard-coded 'project_only=True' at 
the database layer? This seems like something that should be enforced at 
the API layer and not at the database layer. It reminded me of an effort 
we had a few years ago where we removed other hard-coded policy 
enforcement from the database layer [1][2]. I've uploaded a WIP patch to 
demonstrate the proposed change [3].

Can anyone think of any potential problems with doing this? I'd like to 
be able to remove it so that operators are able use policy to allow 
non-admin users with appropriately configured roles to run server actions.

Cheers,
-melanie

[1] https://blueprints.launchpad.net/nova/+spec/nova-api-policy-final-part
[2] 
https://review.openstack.org/#/q/topic:bp/nova-api-policy-final-part+(status:open+OR+status:merged)
[3] https://review.openstack.org/637010