any value for quota project id can be updated

Bug #1037373 reported by Zhou ShaoYu
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Eoghan Glynn

Bug Description

no check for whether tenant id exists,like "axx" in the request url followed
curl -X "PUT" -H "x-auth-token:33fcd117c0864a85b63bb4da3194f6c1" -H "Content-type:application/json" -d '{"quota_set":{"injected_file_content_bytes":-1}}' http://localhost:8774/v2/149696bd1d1941afbeeb986b4e0fa75a/os-quota-sets/axx

Eoghan Glynn (eglynn)
Changed in nova:
assignee: nobody → Eoghan Glynn (eglynn)
status: New → Confirmed
Revision history for this message
Eoghan Glynn (eglynn) wrote :

The main issues here are:

 (a) DB pollution with the quota bounding a non-existent project that never gets enforced

 (b) the lack of feedback when a user fat-fingers the project ID in a call to nova-manage setting the quota

Other than that, there are no ill-effects that I can see, but it certainly should be fixed in any case for Folsom.

Changed in nova:
importance: Undecided → Low
milestone: none → folsom-rc1
Eoghan Glynn (eglynn)
Changed in nova:
status: Confirmed → In Progress
Revision history for this message
Eoghan Glynn (eglynn) wrote :

OK, so it turns out that this is problematic for two reasons:

1. In the keystone auth case, the configuration required to validate the tenant ID is bound to paste config for the keystone auth_token middleware, as opposed to general nova configuration. This config should be refactored so that its located in the general nova.conf, to avoid the need for users to ever edit paste config, and also to make it available to other nova code (such as the quota project ID validation case at hand). While this change is warranted, its out of scope for Folsom at this late stage.

2. In the noauth case, the project ID can be any value what-so-ever, so the validation doesn't arise and wouldn't add any value. Its currently not easily detectable within an API extension whether noauth is being used, as the context is populated in any case with auth-related headers.

For the reasons set out above, lets punt this issue to Grizzly-1.

Changed in nova:
milestone: folsom-rc1 → none
status: In Progress → Confirmed
Revision history for this message
David Geng (genggjh) wrote :

Hi Eoghan, what's the progress of this issue? We have many testers in our project are complaining this bad user experience.
When update the quota we have to provide the exactly tenant id and without any validation, once we provide a tenant name or a wrong tenant id, the quota can not be updated as exception.

Revision history for this message
Thang Pham (thang-pham) wrote :

There is a blueprint to validate tenant and user IDs that is pending: It should resolve this bug and well as many other identical bugs.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related blueprints

Remote bug watches

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