<p dir="ltr"><br>
Le 23 avr. 2015 04:49, "Alex Xu" <<a href="mailto:soulxu@gmail.com">soulxu@gmail.com</a>> a écrit :<br>
><br>
><br>
><br>
> 2015-04-23 6:55 GMT+08:00 Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com">mriedem@linux.vnet.ibm.com</a>>:<br>
>><br>
>><br>
>><br>
>> On 4/22/2015 8:32 AM, Sylvain Bauza wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> By discussing on a specific bug [1], I just discovered that the admin<br>
>>> context check which was done at the DB level has been moved to the API<br>
>>> level thanks to the api-policy-v3 blueprint [2]<br>
>>><br>
>>> That behaviour still leads to a bug if the operator wants to change an<br>
>>> endpoint policy by leaving it end-user but still continues to be denied<br>
>>> because of that, as it will forbid any non-admin user to call the<br>
>>> methods (even if authorize() grants the request)<br>
>>><br>
>>> I consequently opened a bug [3] for this but I'm also concerned about<br>
>>> the backportability of that and why it shouldn't fixed in v2.0 too.<br>
>>><br>
>>> Releasing the check by removing it sounds an acceptable change, as it<br>
>>> fixes a bug without changing the expected behaviour [4]. The impact of<br>
>>> the change sounds also minimal with a very precise scope (ie. leave the<br>
>>> policy rules work as they are expected) [5]<br>
>>><br>
>>> Folks, thoughts ?<br>
>>><br>
>>> -Sylvain<br>
>>><br>
>>> [1] <a href="https://bugs.launchpad.net/nova/+bug/1447084">https://bugs.launchpad.net/nova/+bug/1447084</a><br>
>>> [2]<br>
>>> <a href="https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z">https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z</a><br>
>>><br>
>>> [3] <a href="https://bugs.launchpad.net/nova/+bug/1447164">https://bugs.launchpad.net/nova/+bug/1447164</a><br>
>>> [4]<br>
>>> <a href="https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK">https://wiki.openstack.org/wiki/APIChangeGuidelines#Generally_Considered_OK</a><br>
>>> "Fixing a bug so that a request which resulted in an error response<br>
>>> before is now successful"<br>
>>> [5] <a href="https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy">https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy</a><br>
>>><br>
>>> __________________________________________________________________________<br>
>>> OpenStack Development Mailing List (not for usage questions)<br>
>>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
>>><br>
>><br>
>> I don't disagree, see bug 1168488 from way back in grizzly.<br>
>><br>
>> The only thing would be we'd have to make sure the default rule is admin for any v2 extensions which are enforcing an admin context today.<br>
><br>
><br>
> Agree, if we want to fix those for v2, we need make sure the default rule is admin.<br>
><br>
> And do you mean [3] want to fix this for v2 both in Kilo and Liberty?<br>
><br>
> For liberty, we can do that, but I think we will switch to v2.1 very soon. Not sure it is still worth to do that.<br>
><br>
> For kilo, some of api is pretty easy to fix by just removing 'require_admin_context()'. But there still have many of policy patches didn't merged into the master yet. like:<br>
> <a href="https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z">https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/nova-api-policy-final-part,n,z</a><br>
> <a href="https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z">https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/v3-api-policy,n,z</a><br>
> <a href="https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_qutoa_hardcode_permission,n,z">https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_qutoa_hardcode_permission,n,z</a><br>
> <a href="https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_quotaclass_hardcode_permission,n,z">https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:remove_quotaclass_hardcode_permission,n,z</a><br>
><br>
> Should we back-port them all?</p>
<p dir="ltr">Wrt all the necessary backports, I'm eventually rather in favor of an opportunistic approach and only backport what has been reported as a bug, ie. [1]</p>
<p dir="ltr">That has also the benefit of not proposing a stable patch which was not cherry-picked (like providing an elevated context), which I disapprove.</p>
<p dir="ltr">-Sylvain</p>
<p dir="ltr">><br>
>><br>
>><br>
>> -- <br>
>><br>
>> Thanks,<br>
>><br>
>> Matt Riedemann<br>
>><br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
</p>