On Tue, 19 Feb 2019 10:42:32 -0600, Matt Riedemann <mriedemos@gmail.com> wrote:
On 2/18/2019 8:22 PM, melanie witt wrote:
Right, that is the proposal in this email. That we should remove project_only=True and let the API policy check handle whether or not the user from a different project is allowed to get the instance. Otherwise, users are not able to use policy to control the behavior because it is hard-coded in the database layer.
I think this has always been the long-term goal and I remember a spec from John about it [1] but having said that, the spec was fairly complicated (to me at least) and sounds like there would be a fair bit of auditing of the API code we'd need to do before we can remove the DB API check, which means it's likely not something we can complete at this point in Stein.
For example, I think we have a lot of APIs that run the policy check on the context (project_id and user_id) as the target before even pulling the resource from the database, and the resource itself should be the target, right?
Thanks for the link -- I hadn't seen this spec yet. Yes, Alex just pinged me in #openstack-nova and now I finally understand his point that I kept missing before. He tried a test with my WIP patch and a user from project A was able to 'nova show' an instance from project B, even though the policy was set to 'rule:admin_or_owner'. The reason is because when the instance project/user isn't passed as a target to the policy check, the policy check for the request context project_id won't do anything. There's nothing for it to compare project_id with. This is interesting because it makes me wonder, what does a policy check like that [2] do then? It will take more learning on my part about the policy system to understand it. -melanie [2] https://github.com/openstack/nova/blob/3548cf59217f62966a21ea65a8cb744606431...