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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
