| 2014-08-03 18:54:07 |
John Griffith |
description |
Currently the types api module in Cinder grabs a specified volume_type directly from the volume_types module which does a context elevation. This means that the returned volume_type object that is then just fed directly into the general view_builder includes the extra_specs info which we've always considered "admin" data.
We should at the very least check the credentials of the caller in the api/v<n>/types module, and filter out the extra-specs for non-admin users. Someone may want to make a policy for this... but typically we don't want to allow things like volume_backend_name to be exposed to the end user.
This also exposes some sloppiness we've gotten into over time regarding calls directly to modules versus calls that go through cinder/volume/api.py. There are def cases where it seems silly to create a wrapper in volume/api, and at one point volume/api was in fact thought of specifically for volume api actions (that's changed quite a bit). Anyway, the point is I think we should discuss having a consistent design and at least an 'expected' sequence. |
Currently the types api module in Cinder grabs a specified volume_type directly from the volume_types module which does a context elevation. This means that the returned volume_type object that is then just fed directly into the general view_builder includes the extra_specs info which we've always considered "admin" data.
Example response from view_builder:
{'volume_type': {'extra_specs': {u'volume_backend_name': u'lvmdriver-1'}, 'name': u'lvmdriver-1', 'id': 'd30ce89f-57d0-43df-a70b-e75af1757357'}}
We should at the very least check the credentials of the caller in the api/v<n>/types module, and filter out the extra-specs for non-admin users. Someone may want to make a policy for this... but typically we don't want to allow things like volume_backend_name to be exposed to the end user.
This also exposes some sloppiness we've gotten into over time regarding calls directly to modules versus calls that go through cinder/volume/api.py. There are def cases where it seems silly to create a wrapper in volume/api, and at one point volume/api was in fact thought of specifically for volume api actions (that's changed quite a bit). Anyway, the point is I think we should discuss having a consistent design and at least an 'expected' sequence. |
|
