project ID not honored in requests

Bug #1666695 reported by Thomas Maddox
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
craton
Fix Released
Critical
Sulochan Acharya

Bug Description

When passing "project_id" in a create request for regions/cells (most likely others), it seems the "X-Auth-Project" attribute is used for the "project_id" reference for the created object, not the one in the request body:

$ curl -X POST -s http://127.0.0.1:8080/v1/regions -H "Content-Type: application/json" -H "X-Auth-Token: demo_root" -H "X-Auth-User: demo_root" -H "X-Auth-Project: b9f10eca66ac4c279c139d01e65f96b4" -d '{"name": "demo2_region2", "project_id": "51b4e063-b141-4cb4-9899-21d28d7c4d9e"}' | jq
{
  "created_at": "2017-02-21T21:47:00.756762",
  "id": 6,
  "name": "demo2_region2",
  "note": null,
  "project_id": "b9f10eca66ac4c279c139d01e65f96b4",
  "updated_at": null,
  "variables": {}
}

$ curl -X POST -s http://127.0.0.1:8080/v1/cells -H "Content-Type: application/json" -H "X-Auth-Token: demo_root" -H "X-Auth-User: demo_root" -H "X-Auth-Project: b9f10eca66ac4c279c139d01e65f96b4" -d '{"name": "demo2_region1_cell1", "project_id": "51b4e063-b141-4cb4-9899-21d28d7c4d9e", "region_id": 7}' | jq
{
  "created_at": "2017-02-21T21:50:13.611528",
  "id": 5,
  "name": "demo2_region1_cell1",
  "note": null,
  "project_id": "b9f10eca66ac4c279c139d01e65f96b4",
  "region_id": 7,
  "updated_at": null,
  "variables": {}
}

Revision history for this message
Sulochan Acharya (sulochan-acharya) wrote :

I don't think project_id is required (or honored) in request body.
See: https://github.com/openstack/craton/commit/1a858f2d2e1f3afa7879cefd0c85639cc009a5b2

Revision history for this message
Thomas Maddox (thomas-maddox) wrote :

Not required, no. But, why allow it if it doesn't do anything? That's confusing.

Revision history for this message
Jim Baker (jimbaker) wrote :

This is very problematic for one case: we need to separate the desired project_id for a user, etc, from the project_id that we use to authenticate a specific user with. (As we add real RBAC, this will become more pronounced.)

This bug is now impacting the creation of new users associated with new projects. Example:

$ echo $OS_USERNAME $OS_PROJECT_ID
bootstrap ef668931-a082-41bc-96c9-61667178f6da

$ craton-post v1/projects name=foobar
HTTP/1.0 201 CREATED
Content-Length: 158
Content-Type: application/json
Date: Wed, 15 Mar 2017 04:10:07 GMT
Location: http://127.0.0.1:7780/v1/projects/d8a4d2ee-868e-4f34-98a1-3f1cad481319
Server: WSGIServer/0.2 CPython/3.5.1
x-openstack-request-id: req-2ff476e3-455b-44f0-abfc-ea8be4b403da

{
    "created_at": "2017-03-15T04:10:07.273426",
    "id": "d8a4d2ee-868e-4f34-98a1-3f1cad481319",
    "name": "foobar",
    "updated_at": null,
    "variables": {}
}

$ craton-post v1/users username=baz project_id=d8a4d2ee-868e-4f34-98a1-3f1cad481319
HTTP/1.0 201 CREATED
Content-Length: 233
Content-Type: application/json
Date: Wed, 15 Mar 2017 04:10:39 GMT
Location: http://127.0.0.1:7780/v1/users/2
Server: WSGIServer/0.2 CPython/3.5.1
x-openstack-request-id: req-0c3b861c-efae-4072-91eb-57256a774814

{
    "api_key": "51cccf96-873b-47c2-a82f-78203188018a",
    "created_at": "2017-03-15T04:10:39.738189",
    "id": 2,
    "is_admin": false,
    "project_id": "ef668931-a082-41bc-96c9-61667178f6da",
    "updated_at": null,
    "username": "baz"
}

So the bootstrap user cannot create new users in a new project - which means it's not really fulfilling its role as "bootstrap".

Changed in craton:
milestone: none → v0.1.0
status: New → Confirmed
importance: Undecided → Critical
Changed in craton:
assignee: nobody → Sulochan Acharya (sulochan-acharya)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to craton (master)

Fix proposed to branch: master
Review: https://review.openstack.org/446972

Changed in craton:
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to craton (master)

Reviewed: https://review.openstack.org/446938
Committed: https://git.openstack.org/cgit/openstack/craton/commit/?id=9ddf2c4cd59f69468218ac047b296f7e37899963
Submitter: Jenkins
Branch: master

commit 9ddf2c4cd59f69468218ac047b296f7e37899963
Author: Sulochan Acharya <email address hidden>
Date: Fri Mar 17 10:12:49 2017 +0000

    Include project_id only where needed

    Currently project_id is allowed in request body
    for all request, however, its not honered since project_id
    is pulled from headers.

    This commit separates the need for project_id only where
    its needed. For instance, in users we expect project_id
    to allow creating users for different projects or we
    expect project_id in response body.

    Partial-Bug: 1666695

    Change-Id: Ie5fac9ef4c305ff7e67fe32855ca8100a8adfa82

Revision history for this message
OpenStack Infra (hudson-openstack) wrote :

Reviewed: https://review.openstack.org/446972
Committed: https://git.openstack.org/cgit/openstack/craton/commit/?id=5f0e8d762214618b05b54a3f1594c697bf304d86
Submitter: Jenkins
Branch: master

commit 5f0e8d762214618b05b54a3f1594c697bf304d86
Author: Sulochan Acharya <email address hidden>
Date: Fri Mar 17 11:24:19 2017 +0000

    Create user under project_id passed in request

    Currently when user is created, its taking the project_id
    parameter from the user who is creating the request.
    However, given root users are expected to be ablet to create
    users for all projects this patch modifies the behaviour
    and ensure that the user creation is always under the
    project_id parameter that is passed in.

    Functional test for create call is added. However,
    function test coverage is not complete. It needs to
    be addressed as a separate commit, tacked in
    issue: 1674287

    Closes Bug: 1666695
    Partial-Bug: 1674287
    Parent: Ie5fac9ef4c305ff7e67fe32855ca8100a8adfa82

    Change-Id: I19fb901ad41edeeb0a92f41264867a768a207fce

Changed in craton:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.