On Tue, 2013-07-23 at 23:47 +0100, Henry Nash wrote: > ...the problem is that if the object does not exists we might not be able > tell whether the use is authorized or not (since authorization might depend > on attributes of the object itself)....so how do we know wether to lie or not?
If the error you return is always 'Not Found', why do you care ? Simo. > Henry > On 23 Jul 2013, at 21:23, David Chadwick wrote: > > > > > > > On 23/07/2013 19:02, Henry Nash wrote: > >> One thing we could do is: > >> > >> - Return Forbidden or NotFound if we can determine the correct answer > >> - When we can't (i.e. the object doesn't exist), then return NotFound > >> unless a new config value 'policy_harden' (?) is set to true (default > >> false) in which case we translate NotFound into Forbidden. > > > > I am not sure that this achieves your objective of no data leakage through > > error codes, does it? > > > > Its not a question of determining the correct answer or not, its a question > > of whether the user is authorised to see the correct answer or not > > > > regards > > > > David > >> > >> Henry > >> On 23 Jul 2013, at 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. > >>> > >>>> > >>>> 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. 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. > >>> > >>> > >>> > >>> > >>>> > >>>> 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@lists.openstack.org > >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>>>> > >>>> > >>>> _______________________________________________ > >>>> OpenStack-dev mailing list > >>>> OpenStack-dev@lists.openstack.org > >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> > >>> _______________________________________________ > >>> OpenStack-dev mailing list > >>> OpenStack-dev@lists.openstack.org > >>> <mailto:OpenStack-dev@lists.openstack.org> > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > >> > >> > >> _______________________________________________ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
