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:
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.
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: 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.
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/
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.