Open Stack

Hi Phil,

I think the checking of adminness at the db layer should be removed now that we are checking everything via policy. This seems like something very useful to tackle in Havana. We might want to do a bit of an audit to make sure there isn't anything allowed that shouldn't be, but I think the extra layer of checks is just getting in the way at the moment.

Vish

On Feb 27, 2013, at 10:57 AM, "Day, Phil" <philip.day at hp.com> wrote:

> Hi Folks,
>  
> With the policy controls now in place, I’m wondering if we can remove at least some of the @require_admin_context decorators in the DB layer.
>  
> The particular use case I was trying to address is to create a role in Keystone that would allow selected users to be able to make quota changes, without having to give them the admin role.    Seems that this is easy enough to do in principle in policy.json – but the action will currently still get blocked at the DB layer.
>  
> I know that some other operations (like lock) get around this by calling context.elevated() after the policy check, but wondered if there was a reason for going down that route rather than just removing the “must be admin” check in the DB layer ?
>  
> Thanks
> Phil
> _______________________________________________
> 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/20130228/e9d7ff61/attachment.html>