Open Stack

On 02/14/2019 12:19 PM, melanie witt wrote:
> 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.

+1 to removing these hard-coded policy-like things.

I can't think of any potential "problems" with removing the project_only 
thing, actually.

Best,
-jay