floatingip-create doesn't check if tenant_id exists or enabled

Bug #1200585 reported by Jian Wen on 2013-07-12
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
neutron
Medium
Unassigned

Bug Description

how to reproduce:
$ quantum floatingip-create --tenant-id 111 public

Created a new floatingip:
+---------------------+--------------------------------------+
| Field | Value |
+---------------------+--------------------------------------+
| fixed_ip_address | |
| floating_ip_address | 172.24.4.231 |
| floating_network_id | 05fa4ce3-b834-40d1-bf9b-4794f057f40b |
| id | 520b88c2-3d70-4698-aef5-620275e50cf8 |
| port_id | |
| router_id | |
| tenant_id | 111 |
+---------------------+--------------------------------------+

expect result:
HTTP 404
Because tenant-id doesn't exist.

Jian Wen (wenjianhn) on 2013-07-12
Changed in neutron:
assignee: nobody → Jian Wen (wenjianhn)

How do you plan to solve this issue?
This is actually common to every quantum API call; the tenants are stored in keystone.

It is my opinion that it won't be a great idea to validate the tenant with keystone for each API call.
Personally, I would consider this bug as invalid.
Only admins can create resourceon behalf of other tenants, and if they create a resource for a non-existent tenant, nobody beyond the admin itself would be able to access that resource.

Mark McClain (markmcclain) wrote :

tenant_ids are not validated against keystone for any other resource. This is an admin only operation and we cannot create a constraint that would work properly in all cases due to the federated nature of OpenStack databases.

Changed in neutron:
status: New → Invalid
Jian Wen (wenjianhn) wrote :

We don't need to validate the tenant_id for each api call. Only tenant_id
set by admin in the command is needed to validate against keystone by neutron.
Mostly, neutron server gets tenant_id from keystone by using the X-Auth-Token
http header.
We can always get a valid tenant_id by using context.tenant_id.

For example, an admin creating a network for a non-existent tenant_id 111.
REQ: curl -i http://192.168.11.3:9696/v2.0/floatingips.json -X POST -H "X-Auth-Token: ..." -H "Content-Type: application/json" -H "Accept: application/json" -H "User-Agent: python-quantumclient" -d '{"floatingip": {"floating_network_id": "05fa4ce3-b834-40d1-bf9b-4794f057f40b", "tenant_id": "111"}}'

Neutron server is able to get the admin tenant_id by using context.tenant_id which is valid.
The tenant_id that we need to validate separately is 111 in the request body.
we need to tell the admin if he is doing something wrong.

affected commands:
floatingip-create, lb-member-create, lb-pool-create, lb-vip-create, net-create,
port-create, security-group-create, security-group-rule-create,
subnet-create and quota-update.

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

Changed in neutron:
status: Invalid → In Progress
tags: added: l3-ipam-dhcp
Jian Wen (wenjianhn) on 2013-07-25
Changed in neutron:
status: In Progress → Invalid

I agree with Jian Wen - this is still a bug that we don't validate the tenant-id and the assumption an administrator knows what they are doing is not always true. I disagree with marking it as invalid - it is a valid concern and I would at least mark it as a known bug.

lee jian (leejian0612) wrote :

I meet a similar question , the root cause is that, when using admin user to create networking resource, he can override tenant_id attribute as he liked, even though the tenant may not exist, for example, I can use admin to create a network with invalid tenant_id, "neutron net-create --tenant-id aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa test".
To solve this problem, I add a check to the function _get_tenant_id_for_create in neutron/db/common_db_mixin.py to make sure the tenant_id setted by admin user is valid.

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

Changed in neutron:
assignee: Jian Wen (wenjianhn) → lee jian (leejian0612)
status: Invalid → In Progress
Changed in neutron:
importance: Undecided → Medium

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/186264
Reason: This review is > 4 weeks without comment and currently blocked by a core reviewer with a -2. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -2 on this review to ensure you address their concerns.

Miguel Lavalle (minsel) wrote :

Marked this bug incomplete since there hasn't been activity for several months with and fix is abandoned with a -2

Changed in neutron:
status: In Progress → Incomplete
Changed in neutron:
assignee: lee jian (leejian0612) → nobody
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers