Open Stack

Hi Vish,

Actually I was coming round to the other way of approach this - leave the checks in the DB layer but elevate the context after the policy check (like lock does already).

My thinking is that any audit we do of the code now to check there are no non-admin paths to the updates will only be as good as how well we remember to keep checking in future reviews, whereas elevating the context right by where you make the policy check seems a fairly natural and obvious thing to do for API calls that are only going to go on and update the DB.

I was hoping on that basis that we could clear a few of these as bugs (on the basis that the current code can't enforce anything other than the default policy)  - for example quota updates and live migration are things I'd like to be able to delegate to a role other than admin.

Thoughts ?
Phil


From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]
Sent: 01 March 2013 03:14
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] Do we still need "require_admin_context" on DB opertaions in Nova now we have policy.json ?

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<mailto: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<mailto: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/20130306/a9535fec/attachment.html>