[openstack-dev] [Climate] How we agree to determine that an user has admin rights ?

Sylvain Bauza sylvain.bauza at bull.net
Wed Nov 20 13:49:10 UTC 2013


Well, I'm guessing the best way is the contrary, Swann needing to rebase 
from the change I proposed about policies. The latter is still as draft, 
committing myself to finish it by today.

-Sylvain

Le 20/11/2013 12:42, Dina Belova a écrit :
> I suppose it's ok - just rebase from Swann's commit to have is_admin 
> param to use.
>
>
> On Wed, Nov 20, 2013 at 3:21 PM, Sylvain Bauza <sylvain.bauza at bull.net 
> <mailto:sylvain.bauza at bull.net>> wrote:
>
>     Hi Yuriy,
>
>     Le 20/11/2013 11:56, Yuriy Taraday a écrit :
>>     Looking at implementations in Keystone and Nova, I found the only
>>     use for is_admin but it is essential.
>>
>>     Whenever in code you need to run a piece of code with admin
>>     privileges, you can create a new context with  is_admin=True
>>     keeping all other parameters as is, run code requiring admin
>>     access and then revert context back.
>>     My first though was: "Hey, why don't they just add 'admin' role
>>     then?". But what if in current deployment admin role is named
>>     like 'TheVerySpecialAdmin'? What if user has tweaked policy.json
>>     to better suite one's needs?
>>
>>     So my current understanding is (and I suggest to follow this logic):
>>     - 'admin' role in context.roles can vary, it's up to cloud admin
>>     to set necessary value in policy.json;
>>     - 'is_admin' flag is used to elevate privileges from code and
>>     it's name is fixed;
>>     - policy check should assume that user is admin if either special
>>     role is present or is_admin flag is set.
>
>
>     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 ?
>
>
>     [1]
>     https://github.com/openstack/nova/blob/master/etc/nova/policy.json#L2
>     [2] https://github.com/openstack/nova/blob/master/nova/policy.py#L116
>     [3]
>     https://github.com/openstack/nova/blob/master/nova/context.py#L102
>
>     _______________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> -- 
>
> Best regards,
>
> Dina Belova
>
> Software Engineer
>
> Mirantis Inc.
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


More information about the OpenStack-dev mailing list