<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 23, 2013 at 10:40 AM, Henry Nash <span dir="ltr"><<a href="mailto:henryn@linux.vnet.ibm.com" target="_blank">henryn@linux.vnet.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi<br>
<br>
As part of bp <a href="https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target" target="_blank">https://blueprints.launchpad.net/keystone/+spec/policy-on-api-target</a> 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.<br>

<br>
<a href="https://review.openstack.org/#/c/38308/" target="_blank">https://review.openstack.org/#/c/38308/</a><br>
<br>
A couple of points:<br>
<br>
- 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.<br>
</blockquote><div><br></div><div>This could be based on whether debug mode is enabled or not... in debug mode, raise a Forbidden for an object that exists but you don't have access to. In normal mode, suppress that extra (potentially sensitive) information by convert Forbidden errors into 404's. Either way, the ID's would be very difficult to guess, so I'm not sure how much trouble it's worth?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
- 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<br></blockquote><div>
<br></div><div>That would be MUCH appreciated -- definitely belongs in openstack-manuals but I'm not sure which book would be most appropriate?</div><div><br></div><div>  <a href="https://github.com/openstack/openstack-manuals/tree/master/doc/src/docbkx">https://github.com/openstack/openstack-manuals/tree/master/doc/src/docbkx</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div><br></div>-Dolph
</div></div>