Open Stack

On Wed, Nov 20, 2013 at 10:24 AM, Yuriy Taraday <yorik.sar at gmail.com> wrote:

>
> On Wed, Nov 20, 2013 at 3:21 PM, Sylvain Bauza <sylvain.bauza at bull.net>wrote:
>
>> Yes indeed, that's something coming into my mind. Looking at Nova, I
>> found a "context_is_admin" policy in policy.json allowing you to say which
>> role is admin or not [1] and is matched in policy.py [2], which itself is
>> called when creating a context [3].
>>
>> I'm OK copying that, any objections to it ?
>>
>
> I would suggest not to copy this stuff from Nova. There's a lot of legacy
> there and it's based on old openstack.common.policy version. We should rely
> on openstack.common.policy alone, no need to add more checks here.
>
>
>> [1] https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L2
>>
>
> This rule is here just to support
>
>
>> [2] https://github.com/openstack/nova/blob/master/nova/policy.py#L116
>>
>
> this, which is used only
>
>
>> [3] https://github.com/openstack/nova/blob/master/nova/context.py#L102
>>
>
> here. This is not what I would call a consistent usage of policies.
>
>>
> If we need to check access rights to some method, we should use an
> appropriate decorator or helper method and let it check appropriate policy
> rule that would contain "rule:admin_required", just like in Keystone:
> https://github.com/openstack/keystone/blob/master/etc/policy.json.
>

++ Define actual policy rules with a suggested policy.json file, but do NOT
hardcode a definition of "admin". Allow the deployer to define more
granular policy. oslo.policy makes this pretty easy. If you're looking at
keystone, be sure to look at how we protect v3 controller methods (which
ask the policy engine, "does the requestor have authorization to perform
this operation?"), NOT how we protect v2 controller methods (which ask the
policy engine, "does the requestor have a magical pre-defined role?"
regardless of what operation is actually being performed).


>
> context.is_admin should not be checked directly from code, only through
> policy rules. It should be set only if we need to elevate privileges from
> code. That should be the meaning of it.
>

is_admin is a short sighted and not at all granular -- it needs to die, so
avoid imitating it.


>
>
> --
>
> Kind regards, Yuriy.
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 

-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/17065e98/attachment.html>