[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