<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p>I am still confused how the "cloud admin" role is fulfilled in
      Liberty release. For example, I used "nova --debug delete" to see
      how the project:admin/user:admin deletes an instance of the demo
      project. Basically, we use the project:admin/user:admin token to
      get a list of instances for all tenants and then reference the
      instance of demo using the admin project tenant-id in the:</p>
    <p>curl -g -i -X DELETE
      <a class="moz-txt-link-freetext"
href="http://172.31.5.216:8774/v2.1/85b0992a5845455083db84d909c218ab/servers/6c876149-ecc4-4467-b727-9dff7b059390">http://172.31.5.216:8774/v2.1/85b0992a5845455083db84d909c218ab/servers/6c876149-ecc4-4467-b727-9dff7b059390</a></p>
    <p>So 85b0992a5845455083db84d909c218ab is admin tenant id, and
      6c876149-ecc4-4467-b727-9dff7b059390 is owned by demo project.</p>
    <p>I am able to reproduce this using curl commands - but what's
      confusing me is that the token I get from keystone clearly shows
      is_admin is 0:</p>
    <p>"user": {"username": "admin", "roles_links": [], "id":
      "9b29c721bc3844a784dcffbb8c8a47f8", "roles": [{"name": "admin"}],
      "name": "admin"}, "metadata": {<font color="#cc0000">"is_admin": 0</font>,
      "roles": ["6a6893ea36394a2ab0b93d225ab01e25"]}}}</p>
    <p>And the rules for compute:delete seem to require is_admin to be
      true. nova/policy.json has two rules for "compute:delete":</p>
    <p><font color="#cc0000"><i><font size="-1">Line  81    
            "compute:delete": "rule:admin_or_owner",<br>
            Line  88     "compute:delete": "",</font></i></font></p>
    <p>First question - why is line 88 needed?</p>
    <p>Second, on line  3 admin_or_owner definition requires is_admin to
      be true:</p>
    <p><font color="#cc0000"><i><font size="-1">    "admin_or_owner": 
            "is_admin:True or project_id:%(project_id)s",</font></i></font></p>
    <p> which if my understanding is correct, is never true unless the
      keystone admin_token is used, and is certainly not true the token
      I got using curl. So why is my curl request using this token able
      to delete the instance?</p>
    <p>Thanks,</p>
    <p>Reza<br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 9/2/2016 12:51 PM, Morgan Fainberg
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAGnj6atWb+MtLurGwZAy_CBz-22ZmiATUpEx-9_EW5dCUBVeng@mail.gmail.com"
      type="cite">
      <p dir="ltr">On Sep 2, 2016 09:39, "rezroo" <<a
          moz-do-not-send="true" href="mailto:openstack@roodsari.us">openstack@roodsari.us</a>>
        wrote:<br>
        ><br>
        > Hello - I'm using Liberty release devstack for the below
        scenario. I have created project "abcd" with "john" as Member.
        I've launched one instance, I can use curl to list the instance.
        No problem.<br>
        ><br>
        > I then modify /etc/nova/policy.json and redefine
        "admin_or_owner" as follows:<br>
        ><br>
        >     "admin_or_owner":  "role:admin or is_admin:True or
        project_id:%(project_id)s",<br>
        ><br>
        > My expectation was that I would be able to list the
        instance in abcd using a token of admin. However, when I use the
        token of user "admin" in project "admin" to list the instances I
        get the following error:<br>
        ><br>
        > stack@vlab:~/token$ curl <a moz-do-not-send="true"
href="http://localhost:8774/v2.1/378a4b9e0b594c24a8a753cfa40ecc14/servers/detail">http://localhost:8774/v2.1/378a4b9e0b594c24a8a753cfa40ecc14/servers/detail</a>
        -H "User-Agent: python-novaclient" -H "Accept: application/json"
        -H "X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token:
        f221164cd9b44da6beec70d6e1f3382f"<br>
        > {"badRequest": {"message": "Malformed request URL: URL's
        project_id '378a4b9e0b594c24a8a753cfa40ecc14' doesn't match
        Context's project_id 'f73175d9cc8b4fb58ad22021f03bfef5'",
        "code": 400}}<br>
        ><br>
        > 378a4b9e0b594c24a8a753cfa40ecc14 is project id of abcd and
        f73175d9cc8b4fb58ad22021f03bfef5 is project id of admin.<br>
        ><br>
        > I'm confused by this behavior and the reported error,
        because if the project id used to acquire the token is the same
        as the project id in /servers/detail then I would be an "owner".
        So where is the "admin" in "admin_or_owner"? Shouldn't the
        "role:admin" allow me to do whatever functionality
        "rule:admin_or_owner" allows in policy.json, regardless of the
        project id used to acquire the token?<br>
        ><br>
        > I do understand that I can use the admin user and project
        to get all instances of all tenants:<br>
        > curl <a moz-do-not-send="true"
href="http://localhost:8774/v2.1/f73175d9cc8b4fb58ad22021f03bfef5/servers/detail?all_tenants=1">http://localhost:8774/v2.1/f73175d9cc8b4fb58ad22021f03bfef5/servers/detail?all_tenants=1</a>
        -H "User-Agent: python-novaclient" -H "Accept: application/json"
        -H "X-OpenStack-Nova-API-Version: 2.6" -H "X-Auth-Token: $1"<br>
        ><br>
        > My question is more centered around why nova has the
        additional check to make sure that the token project id matches
        the url project id - and whether this is a keystone requirement,
        or only nova/cinder and programs that have a project-id in their
        API choose to do this. In other words, is it the developers of
        each project that decide to only expose some APIs for
        administrative functionality (such all-tenants), but restrict
        everything else to owners, or keystone requires this check?<br>
        ><br>
        > Thanks,<br>
        ><br>
        > Reza<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>
        ></p>
      <p dir="ltr">I believe this is a nova specific extra check. There
        is (iirc) a way to list out the instances for a given tenant but
        I do not recall the specifics. </p>
      <p dir="ltr">Keystone does not know anything about the resource
        ownership in Nova. The Nova check is fully self-contained. </p>
      <p dir="ltr">--Morgan<br>
        Please excuse brevity and typos, sent from a mobile device. <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>