floatingip-create doesn't check if tenant_id exists or enabled
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-
| id | 520b88c2-
| port_id | |
| router_id | |
| tenant_id | 111 |
+------
expect result:
HTTP 404
Because tenant-id doesn't exist.
Changed in neutron: | |
assignee: | nobody → Jian Wen (wenjianhn) |
Mark McClain (markmcclain) wrote : | #2 |
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 : | #3 |
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://
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-
subnet-create and quota-update.
Fix proposed to branch: master
Review: https:/
Changed in neutron: | |
status: | Invalid → In Progress |
tags: | added: l3-ipam-dhcp |
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 : | #6 |
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 aaaaaaaaaaaaaaa
To solve this problem, I add a check to the function _get_tenant_
OpenStack Infra (hudson-openstack) wrote : | #7 |
Fix proposed to branch: master
Review: https:/
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:/
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 : | #9 |
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 : | #10 |
[Expired for neutron because there has been no activity for 60 days.]
Changed in neutron: | |
status: | Incomplete → Expired |
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.