Bug 970733 - Keystone API v3 project creation does not validates domain_id
Keystone API v3 project creation does not validates domain_id
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-keystone (Show other bugs)
Unspecified Unspecified
medium Severity medium
: rc
: 4.0
Assigned To: Adam Young
Jeremy Agee
Depends On:
  Show dependency treegraph
Reported: 2013-06-04 13:59 EDT by Pavel Sedlák
Modified: 2016-04-26 10:07 EDT (History)
5 users (show)

See Also:
Fixed In Version: openstack-keystone-2013.2-2.el6ost
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-12-19 19:04:34 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1223036 None None None Never
Red Hat Product Errata RHEA-2013:1859 normal SHIPPED_LIVE Red Hat Enterprise Linux OpenStack Platform Enhancement Advisory 2013-12-20 19:01:48 EST

  None (edit)
Description Pavel Sedlák 2013-06-04 13:59:07 EDT
Description of problem:
When request to create a project (successor of tenant) is sent to Keystone V3 API, with domain_id provided (see link to docs below), it's value is not validated and project is created with invalid association to domain.

See documentation https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#create-project-post-projects for example how the project could/should be created - domain_id is also used there.

Discovered with openstack-keystone-2013.1.1-1.el6ost.

1) Create project with invalid domain:
> localhost:5000
> POST /v3/projects
> {"project":
>   {"domain_id":"invalid-domain",
>    "name":"projectX",
>    "enabled":true}}
results in:
> HTTP - 201 Created
> {'project':
>   {'description': '',
>    'domain_id': 'invalid-domain',
>    'enabled': True,
>    'id': '<PROJECT-ID>',
>    'links': {
>      'self': 'http://localhost:5000/v3/projects/<PROJECT-ID>'},
>    'name': 'projectX'}}

Expected result would be:
> HTTP - 404 Not Found
> with message in body saying 'Could not find domain: invalid-domain'

As that is how other similar requests ends (for ex. creation of Endpoint with invalid service_id).
Comment 2 Adam Young 2013-09-09 17:12:39 EDT
Reproduced upstream.  Problem is a little different than reported:  Since the backend is SQL, it complains of a foreign key constraint.

{"error": {"message": "Conflict occurred attempting to store project. (1452, 'Cannot add or update a child row: a foreign key constraint fails (`keystone`.`project`, CONSTRAINT `project_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `domain` (`id`))')", "code": 409, "title": "Conflict"}}(.venv)

What the origianl reporter saw was likely due to running against the KVS backend which did not check the constraint.
Comment 4 Alan Pevec 2013-12-05 15:08:41 EST
This was included in Havana GA
Comment 7 Jeremy Agee 2013-12-17 14:50:50 EST
Tested with: openstack-keystone-2013.2-3.el6ost.noarch

Confirmed when sql backend was in use the same error as mentioned in c#2
curl -X POST http://localhost:5000/v3/projects -H "content-type: application/json" -H "X-Auth-Token:$TEST_TOKEN" --data '{"project": {"domain_id":"invalid-domain", "name":"projectX", "enabled":true}}'

{"error": {"message": "Conflict occurred attempting to store project. (1452, 'Cannot add or update a child row: a foreign key constraint fails (`keystone`.`project`, CONSTRAINT `project_ibfk_1` FOREIGN KEY (`domain_id`) REFERENCES `domain` (`id`))')", "code": 409, "title": "Conflict"}}

Tested with kvs:
driver = keystone.assignment.backends.kvs.Assignment

service openstack-keystone stop
openstack-db --drop --service keystone
openstack-db --init --service keystone
service openstack-keystone start

No domains exist:
curl -X GET http://localhost:5000/v3/domains  -H "content-type: application/json" -H "X-Auth-Token:ADMIN"

{"domains": [], "links": {"self": "http://localhost:5000/v3/domains", "previous": null, "next": null}}

Tested reported post request and got response:
curl -X POST http://localhost:5000/v3/projects -H "content-type: application/json" -H "X-Auth-Token:ADMIN" --data '{"project": {"domain_id":"invalid-domain", "name":"projectX", "enabled":true}}'

{"project": {"id": "20e03925290544158aeb363374954abe", "enabled": true, "domain_id": "invalid-domain", "links": {"self": "http://localhost:5000/v3/projects/20e03925290544158aeb363374954abe"}, "name": "projectX"}}

Checked and it was saved to kvs:
curl -X GET http://localhost:5000/v3/projects -H "content-type: application/json" -H "X-Auth-Token:ADMIN"

{"links": {"self": "http://localhost:5000/v3/projects", "previous": null, "next": null}, "projects": [{"domain_id": "invalid-domain", "enabled": true, "id": "ba66b34455eb4b47a2efbf676c5577bc", "links": {"self": "http://localhost:5000/v3/projects/ba66b34455eb4b47a2efbf676c5577bc"}, "name": "projectX"}]}

Do we still classify this as expected behavior? Posting without "domain_id" will set it to the expected "default" value.
Comment 8 Jeremy Agee 2013-12-18 13:28:04 EST
this is expected behaviour, to allow v2 and v3 API interoperability. making as verified
Comment 10 errata-xmlrpc 2013-12-19 19:04:34 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


Note You need to log in before you can comment on or make changes to this bug.