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.
Other projects such as Nova (nova flavor-show XX) and Glance (glance image-show XX) publicly show extra_specs and properties.
So, I am not in favor of hiding extra_specs in Cinder. There's no secret information in info such as the backend name.
There's the same exact problem with "keystone endpoint-list" that is marked as 'admin only' but the information are publicly available in the return of (keystone --debug token-get).