Open Stack

On 23 July 2012 23:16, Robert Kukura <rkukura at redhat.com> wrote:

> On 07/23/2012 05:10 PM, Salvatore Orlando wrote:
> > I addressed the same problem on the public networks branch in gerrit in
> > WIP at the moment while we finalize decision on how it should look like
> > on public API.
> >
> > Let me know your thoughts about the implementation. If that is good for
> > you, we can just use that.
>
> I took another look, and maybe it will do the job, which would be great!
>
> I haven't yet made sense of all the changes, but does it boil down to
> putting "enforce_read_policy: True, enforce_write_policy: True" in the
> extended attribute properties?
>
>
Yes - for attributes marked with these decorators, the policy engine would
look for specific policies named <resource>:<attribute_name>

This could even be simplified as it seems that during the meeting a bitmask
based approach has been enabled.
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.
At this stage, we would worry only about "read" and "write" and not care
about the "group" bitmask.

Hence a private network would be 600, while a public one would be a 644.
This mechanism could be extended to attributes, with the provider:vlanid
having a 600.

Please note that this mechanisms is at a very early stage, and any feedback
you could provide will be greatly appreaciated.


> Does this result in POST and PUT operations being rejected if the
> extended attribute is present in the request message and the
> authorization check fails?
>

Yes, if enforce_write_policy is True for that attribute.


>
> Does this result in the extended attribute being silently dropped from
> response message if the authorization check fails?
>

I am not sure I have addresses this case, because probably not important
for the public network use case.
We might want to discuss how to do this.


>
> Finally, does this then require specifying the policy separately for
> each combination of attribute and API operation? One advantage (to me at
> least) of the approach I was taking is that I could simply specify
>
>     "extension:provider_network:get": [["rule:admin_api"]],
>     "extension:provider_network:view": [["rule:admin_api"]],
>
> in the policy.json file.
>
>
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.
If possible I would like to rework all the policy framework to get to a
general format of the following kind:

<resource>:<operation>: [[rule]]

But on the other hand, I don't want to do any change in the policy module
we have imported from openstack-common.

Salvatore

-Bob
>
> > Otherwise, I'll be extremely happy to address all your comments :)
> >
> > You've already done such a lot of great work, that I think it's time for
> > me to address some real issues as well!
> >
> > Salvatore
> >
> > On 23 July 2012 19:58, Robert Kukura <rkukura at redhat.com
> > <mailto:rkukura at redhat.com>> wrote:
> >
> >     Given that Salvatore and Sumit were both concerned about the plugins
> >     doing the authorization for provider network extended attributes (see
> >     patch set 5 of https://review.openstack.org/#/c/9069/), I've been
> >     working on a very simple mechanism to move those policy checks into
> the
> >     core. This mechanism can be used for core attributes as well as
> extended
> >     attributes that require specific authorization to be set or viewed.
> >
> >     The resource attributes map (see quantum/api/v2/attributes.py)
> currently
> >     has boolean properties called allow_post, allow_put, and is_visible
> that
> >     control whether an attribute can be set via create, set via update,
> or
> >     viewed, respectively. My proposed approach is that each of these
> three
> >     properties can still be a boolean, but if it is instead a string,
> that
> >     string is passed to the policy.check function as the name of an
> action,
> >     and the result of the check is used as the boolean would have been
> used.
> >
> >     Please let me know ASAP whether or not you feel this approach is
> >     acceptable, or if you've got any questions or better (simple) ideas.
> I
> >     hope to have it implemented and included in the next
> provider-network BP
> >     patch later today.
> >
> >     Thanks,
> >
> >     -Bob
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20120723/06b7d881/attachment.html>