Open Stack

Hi Yuriy, Dolph et al.

I'm implementing a climate.policy.check_is_admin(ctx) which will look at 
policy.json entry 'context_is_admin' for knowing which roles do have 
elevated rights for Climate.

This check must be called when creating a context for knowing if we can 
allow extra rights. The is_admin flag is pretty handsome because it can 
be triggered upon that check.

If we say that one is bad, how should we manage that ?

-Sylvain



Le 21/11/2013 06:18, Yuriy Taraday a écrit :
> On Wed, Nov 20, 2013 at 9:57 PM, Dolph Mathews 
> <dolph.mathews at gmail.com <mailto:dolph.mathews at gmail.com>> wrote:
>
>     On Wed, Nov 20, 2013 at 10:52 AM, Yuriy Taraday
>     <yorik.sar at gmail.com <mailto:yorik.sar at gmail.com>> wrote:
>
>         On Wed, Nov 20, 2013 at 8:42 PM, Dolph Mathews
>         <dolph.mathews at gmail.com <mailto:dolph.mathews at gmail.com>> wrote:
>
>             is_admin is a short sighted and not at all granular -- it
>             needs to die, so avoid imitating it.
>
>
>          I suggest keeping it in case we need to elevate privileges
>         from code.
>
>
>     Can you expand on this point? It sounds like you want to ignore
>     the deployer-specified authorization configuration...
>
>
> No, we're not ignoring it. In Keystone we have two options to become 
> an admin: either have 'admin'-like role (set in policy.json by 
> deployer) or have 'is_admin' set (the only way in Keystone is to pass 
> configured admin_token). We don't have bootstrap problem in any other 
> services, so we don't need any admin_token. But we might need to run 
> code that requires admin privileges for user that don't have them. 
> Other projects use get_admin_context() or smth like that for this.
> I suggest we keep the option to have such 'in-code sudo' using 
> is_admin that will be mentioned in policy.json, but limit is_admin 
> usage to just that.
>
> -- 
>
> Kind regards, Yuriy.
>
>
> _______________________________________________
> 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/20131121/aef0ffe2/attachment.html>