<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">Le 23/04/2015 09:10, Sylvain Bauza a
      écrit :<br>
    </div>
    <blockquote
cite="mid:CANWE-CnOs0L454G3VpHcV4-+oPDOn9vVar+P49pUZjar1GFswg@mail.gmail.com"
      type="cite">
      <p dir="ltr"><br>
        Le 23 avr. 2015 04:49, "Alex Xu" <<a moz-do-not-send="true"
          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
          moz-do-not-send="true"
          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 moz-do-not-send="true"
          href="https://bugs.launchpad.net/nova/+bug/1447084">https://bugs.launchpad.net/nova/+bug/1447084</a><br>
        >>> [2]<br>
        >>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
          href="https://bugs.launchpad.net/nova/+bug/1447164">https://bugs.launchpad.net/nova/+bug/1447164</a><br>
        >>> [4]<br>
        >>> <a moz-do-not-send="true"
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 moz-do-not-send="true"
          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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
        >>> <a moz-do-not-send="true"
          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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
    </blockquote>
    <br>
    Just a follow-up on that, I'm proposing a change to the approved
    spec to match that discussion :<br>
    <a class="moz-txt-link-freetext" href="https://review.openstack.org/177764">https://review.openstack.org/177764</a><br>
    <br>
    Basically, the idea is not to backport all of the efforts, just make
    sure that default policies are admin-only for the corresponding API
    endpoints that call DB API methods which are decorated by
    require_admin_context()<br>
    <br>
    -Sylvain<br>
    <br>
    <blockquote
cite="mid:CANWE-CnOs0L454G3VpHcV4-+oPDOn9vVar+P49pUZjar1GFswg@mail.gmail.com"
      type="cite">
      <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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
        >> <a moz-do-not-send="true"
          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 moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
        > <a moz-do-not-send="true"
          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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>