Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131120/dbd999a1/attachment.html>