sorry, I lost the ML address again. Alex Xu <soulxu@gmail.com> 于2019年3月12日周二 下午10:55写道：

After review this patch https://review.openstack.org/630769, it probably leads me get some memory back.

The reason we don't support user based policy and pass the instance's context as target is John and Sean mention that we don't have enough test to ensure all the APIs work correctly for cross the tenant user request.

Similar to the patch https://review.openstack.org/630769 try to fix, that patch fix the case admin user to execute a shelve action on normal tenant user. If we enable a tenant user to execute an action on another tenant's server, that will extend the case of https://review.openstack.org/630769, we need ensure it works for that case also.

So hope I remember correctly, just note at here, in case I forget mention that in the future.

melanie witt <melwittt@gmail.com> 于2019年2月20日周三 下午4:16写道：

...

...

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

On Tue, 19 Feb 2019 10:42:32 -0600, Matt Riedemann <mriedemos@gmail.com> wrote: 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?

[1] https://review.openstack.org/#/c/433037/

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...