Open Stack

When writing a previous ISO standard the approach we took was as follows

Lie to people who are not authorised.

So applying this approach to your situation, you could reply Not Found 
to people who are authorised to see the object if it had existed but 
does not, and Not Found to those not authorised to see it, regardless of 
whether it exists or not. In this case, only those who are authorised to 
see the object will get it if it exists. Those not authorised cannot 
tell the difference between objects that dont exist and those that do exist

regards

David


On 23/07/2013 16:40, Henry Nash wrote:
> Hi
>
> As part of bp https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target I have uploaded some example WIP code showing a proposed approach for just a few API calls (one easy, one more complex).  I'd appreciate early feedback on this before I take it any further.
>
> https://review.openstack.org/#/c/38308/
>
> A couple of points:
>
> - One question is on how to handle errors when you are going to get a target object before doing you policy check.  What do you do if the object does not exist?  If you return NotFound, then someone, who was not authorized  could troll for the existence of entities by seeing whether they got NotFound or Forbidden.  If however, you return Forbidden, then users who are authorized to, say, manage users in a domain would aways get Forbidden for objects that didn't exist (since we can know where the non-existant object was!).  So this would modify the expected return codes.
>
> - I really think we need some good documentation on how to bud keystone policy files.  I'm happy to take a first cut as such a thing - what do you think the right place is for such documentation
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>