On Wed, Nov 20, 2013 at 9:57 PM, Dolph Mathews <dolph.math...@gmail.com>wrote: > > On Wed, Nov 20, 2013 at 10:52 AM, Yuriy Taraday <yorik....@gmail.com>wrote: >> >> On Wed, Nov 20, 2013 at 8:42 PM, Dolph Mathews >> <dolph.math...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
