Open Stack

sorry, I lost the ML address again.

Alex Xu <soulxu at 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 at gmail.com> 于2019年2月20日周三 下午4:16写道：
>
>> On Tue, 19 Feb 2019 10:42:32 -0600, Matt Riedemann <mriedemos at 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?
>> >
>> > [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/3548cf59217f62966a21ea65a8cb744606431bd6/nova/api/openstack/compute/servers.py#L425
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190312/3ff49731/attachment.html>