Comment 27 for bug 1617918

Revision history for this message
Julien Danjou (jdanjou) wrote :

I've started working on that, and I've almost finished a PoC of fixing this. It changes the indexer so the resources in database are not usind (id) as primary key, but (id, creator). This works fine, except for the one case – introduced by Ceilometer – where you want to access a resource that you did not created, e.g.:

GET /v1/resource/instance/<someuuid>

If the resource <someuuid> have been created by Ceilometer but your project_id is in it, the current policy allows you to get the resource and its information. With the new scheme, this is not possible anymore because <someuuid> can exists 10 times in the database (e.g. 1 created by Ceilometer and 9 others created by random people). So it'd be very costly to check that which of the 10 you have access to, and if 2 are accessible, that's a problem as the API was not designed to return more than one resource on that URL.

The solution to that problem is either:
1. Break that use case, so there's no sharing of resources/data anymore between tenants using Gnocchi. So in the case of Ceilometer, no user will be able to access data pushed by it anymore.
2. Add a header called X-Created-By, which if provided when requesting "GET /v1/resource/instance/<someuuid>" would specified which resource is trying to be accessed. In the Ceilometer use case, that'd be set to <ceilometer_user_id>:<ceilometer_project_id> and that'll retrieve the right resource.

Another totally different solution that I just thought about, is to keep the current resource id to be the primary key – so id is still unique. However, since this bug is mainly around having the ability to do "gnocchi create resource foobar" with foobar meaning 2 different id for different users, we could change the UUID5 generation mechanism from:

  uuid.uuid5(RESOURCE_ID_NAMESPACE, resource_id_as_string_or_whatever)

to

  uuid.uuid5(RESOURCE_ID_NAMESPACE, resource_id_as_string_or_whatever + ":" + creator)

which would solve that problem quite easily. There *might* be some breakage for people having hardcoded those generated ID somewhere, but if it's not hardcoded, it should be pretty to make work and to upgrade to this new scheme.