[Openstack-security] [Bug 1118066] Re: Nova should confirm quota requests against Keystone
Matt Riedemann
mriedem at us.ibm.com
Tue Oct 6 19:09:56 UTC 2015
I validated today with openstackclient 1.7.0 that you can't show quotas
for a project that doesn't exist:
stack at client:~/devstack$ openstack quota show randomtext
Tenant ID: randomtext does not exist. (HTTP 404) (Request-ID: req-cc9354ea-5935-45db-be60-b86aaf0a20ea)
And I validated that with the v2.1 API you can't request a quota update
on non-standard resources:
{"badRequest": {"message": "Invalid input for field/attribute quota_set.
Value: {u'foo': 20, u'force': True}. Additional properties are not
allowed (u'foo' was unexpected)", "code": 400}}
Because the jsonschema prevents that:
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/quota_sets.py#L28
However, you can create a nova.quotas table entry with an invalid
projectid:
http://paste.openstack.org/show/475511/
So we need to do something about that. I see two options:
1. quota-sets.update should only attempt to update quota on existing
resources - if objects.Quotas.update_limit fails with a not found, we
return 404 on the response. We don't try to create quotas automatically
if they don't exist. However, as part of this we'd need to add a new
quotas-sets.create API since update is handling both create and update
today. This would require a microversion change since it's not backward
compatible.
2. We could change quota-sets.update to try and update first and if we
get a 404, then we validate the projectid against the identity service
before calling objects.Quotas.create_limit. That would at least narrow
the performance impact of validating the projectid against keystone in
the request.
--
You received this bug notification because you are a member of OpenStack
Security, which is subscribed to OpenStack.
https://bugs.launchpad.net/bugs/1118066
Title:
Nova should confirm quota requests against Keystone
Status in OpenStack Compute (nova):
Confirmed
Bug description:
os-quota-sets API should check requests for /v2/:tenant/os-quota-sets/
against Keystone to ensure that :tenant does exist.
POST requests to a non-existant tenant should fail with a 400 error
code.
GET requests to a non-existant tenant may fail with a 400 error code.
Current behavior is to return 200 with the default quotas. A slightly
incompatible change would be to return a 302 redirect to /v2/:tenant
/os-quota-sets/defaults in this case.
Edit (2014-01-22)
Original Description
--------------------
GET /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
returns 200 with the default quotas.
Moreover
POST /v2/:tenant/os-quota-sets/:this_tenant_does_not_exist
with updated quotas succeeds and that metadata is saved!
I'm not sure if this is a bug or not. I cannot find any documentation
on this interface.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1118066/+subscriptions
More information about the Openstack-security
mailing list