Open Stack

On 23/07/2013 18:31, Adam Young wrote:
> On 07/23/2013 12:54 PM, David Chadwick wrote:
>> When writing a previous ISO standard the approach we took was as follows
>>
>> Lie to people who are not authorised.
>
> Is that your verbage?  I am going to reuse that quote, and I would like
> to get the attribution correct.

Yes its my verbiage. But the concept is not. The concept was "tell an 
unauthorised user the same answer regardless of whether the object 
exists or not, so that he cannot gain information from leakage through 
error codes".

>
>>
>> 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
>
> So, to try and apply this to a semi-real example:  There are two types
> of URLs.  Ones that are like this:
>
> users/55FEEDBABECAFE
>
> and ones like this:
>
> domain/66DEADBEEF0000/users/55FEEDBABECAFE
>
>
> In the first case, you are selecting against a global collection, and in
> the second, against a scoped collection.
>
> For unscoped, you have to treat all users as equal, and thus a 404
> probably makes sense.
>
> For a scoped collection we could return a 404 or a 403 Forbidden
> <https://en.wikipedia.org/wiki/HTTP_403> based on the users
> credentials:  all resources under domain/66DEADBEEF0000  would show up
> as 403s regardless of existantce or not if the user had no roles in the
> domain 66DEADBEEF0000.

yes that conforms to the general principle.

  A user that would be allowed access to resources
> in 66DEADBEEF0000  would get a 403 only for an object that existed but
> that they had no permission to read, and 404 for a resource that doesn't
> exist.

Yes, so that the authorised person gets information but the unauthorised 
one does not

regards

David

>
>
>
>
>>
>> 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
>>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>