<br><br><div class="gmail_quote">On 23 July 2012 23:16, Robert Kukura <span dir="ltr"><<a href="mailto:rkukura@redhat.com" target="_blank">rkukura@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 07/23/2012 05:10 PM, Salvatore Orlando wrote:<br>
> I addressed the same problem on the public networks branch in gerrit in<br>
> WIP at the moment while we finalize decision on how it should look like<br>
> on public API.<br>
><br>
> Let me know your thoughts about the implementation. If that is good for<br>
> you, we can just use that.<br>
<br>
</div>I took another look, and maybe it will do the job, which would be great!<br>
<br>
I haven't yet made sense of all the changes, but does it boil down to<br>
putting "enforce_read_policy: True, enforce_write_policy: True" in the<br>
extended attribute properties?<br>
<br></blockquote><div><br></div><div>Yes - for attributes marked with these decorators, the policy engine would look for specific policies named <resource>:<attribute_name></div><div><br></div><div>This could even be simplified as it seems that during the meeting a bitmask based approach has been enabled.</div>
<div>This means I can declare, for each instance of a network a bitmask of access rigths, as it is for files in a linux file system.</div><div>At this stage, we would worry only about "read" and "write" and not care about the "group" bitmask.</div>
<div><br></div><div>Hence a private network would be 600, while a public one would be a 644. </div><div>This mechanism could be extended to attributes, with the provider:vlanid having a 600. </div><div><br></div><div>Please note that this mechanisms is at a very early stage, and any feedback you could provide will be greatly appreaciated.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Does this result in POST and PUT operations being rejected if the<br>
extended attribute is present in the request message and the<br>
authorization check fails?<br></blockquote><div><br></div><div>Yes, if enforce_write_policy is True for that attribute.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Does this result in the extended attribute being silently dropped from<br>
response message if the authorization check fails?<br></blockquote><div><br></div><div>I am not sure I have addresses this case, because probably not important for the public network use case. </div><div>We might want to discuss how to do this.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Finally, does this then require specifying the policy separately for<br>
each combination of attribute and API operation? One advantage (to me at<br>
least) of the approach I was taking is that I could simply specify<br>
<br>
"extension:provider_network:get": [["rule:admin_api"]],<br>
"extension:provider_network:view": [["rule:admin_api"]],<br>
<br>
in the policy.json file.<br>
<br></blockquote><div><br></div><div>I agree on this point, and I did not like the idea of the policy being defined on the operation rather than on the resource.</div><div>If possible I would like to rework all the policy framework to get to a general format of the following kind:</div>
<div><br></div><div><resource>:<operation>: [[rule]]</div><div><br></div><div>But on the other hand, I don't want to do any change in the policy module we have imported from openstack-common.</div><div><br>
</div><div>Salvatore</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-Bob<br>
<div class="im HOEnZb"><br>
> Otherwise, I'll be extremely happy to address all your comments :)<br>
><br>
> You've already done such a lot of great work, that I think it's time for<br>
> me to address some real issues as well!<br>
><br>
> Salvatore<br>
><br>
> On 23 July 2012 19:58, Robert Kukura <<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a><br>
</div><div class="HOEnZb"><div class="h5">> <mailto:<a href="mailto:rkukura@redhat.com">rkukura@redhat.com</a>>> wrote:<br>
><br>
> Given that Salvatore and Sumit were both concerned about the plugins<br>
> doing the authorization for provider network extended attributes (see<br>
> patch set 5 of <a href="https://review.openstack.org/#/c/9069/" target="_blank">https://review.openstack.org/#/c/9069/</a>), I've been<br>
> working on a very simple mechanism to move those policy checks into the<br>
> core. This mechanism can be used for core attributes as well as extended<br>
> attributes that require specific authorization to be set or viewed.<br>
><br>
> The resource attributes map (see quantum/api/v2/attributes.py) currently<br>
> has boolean properties called allow_post, allow_put, and is_visible that<br>
> control whether an attribute can be set via create, set via update, or<br>
> viewed, respectively. My proposed approach is that each of these three<br>
> properties can still be a boolean, but if it is instead a string, that<br>
> string is passed to the policy.check function as the name of an action,<br>
> and the result of the check is used as the boolean would have been used.<br>
><br>
> Please let me know ASAP whether or not you feel this approach is<br>
> acceptable, or if you've got any questions or better (simple) ideas. I<br>
> hope to have it implemented and included in the next provider-network BP<br>
> patch later today.<br>
><br>
> Thanks,<br>
><br>
> -Bob<br>
><br>
><br>
<br>
<br>
</div></div></blockquote></div><br>