Open Stack

We also have a need for various explicit roles which we can't put in place because of this issue.    I have also noticed cases where certain rules aren't granular enough and several  places where an incorrect policy returns an HTTP 500 instead of an HTTP 403.  I'm willing to fix all of this but I would like some buy in on a solution before I submit the code in order to minimize rework.  I can turn this discussion into a blueprint if that is more appropriate.  I would like to propose the following;


1.       Remove the require_admin_context everywhere.  Access to actions will then only be controlled through roles specified through policy.json.

2.       Fix the cases where a single rule can apply to multiple actions.  In most cases the groupings make sense, but making things as granular as possible will allow everyone to define rules and roles in the most flexible way possible.

3.       Fix the error handling so that invalid permissions always return a 403.

4.       Remove the concept of a default rule.  In order to avoid inadvertently opening up any current admin only functions, the default behavior when a rule is not specified should be a failure ( or maybe require admin in this case ).


From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]
Sent: Friday, April 12, 2013 4:54 PM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] view-only use case but APIs are admin-only


On Apr 12, 2013, at 3:22 PM, Brant Knudson <blk at acm.org<mailto:blk at acm.org>> wrote:



We have a use case where we'd like to have operators or managers that should be able to view aspects of the OpenStack system but are not full admins so shouldn't be able to make changes (boot, etc).

We're running into a problem where, despite changing the policy.json to allow the "viewer" role to the "compute_extension:hosts" action in nova policy.json, the API still requires admin authority. It turns out you can set the policy to anything you want, as long as it requires admin. (compute_extension:hosts corresponds to the "nova host-list" command.)

There are other operations that we've identified also require admin despite policy, hypervisor-list/compute_extension:hypervisors, hypervisor-uptime. I haven't gone through all OpenStack APIs to see which work and which don't. ('nova list' does not require admin.)

I opened a bug: https://bugs.launchpad.net/nova/+bug/1168488

Bringing this up on the -dev list to get discussion as to if this is really a bug or intended behavior, and also what a fix might be. I can do the work and submit the changes, but am wondering which direction the community would prefer because I don't want to open up a security exposure.

Potential approaches to fixing, at least compute_extension:hosts:
a) change DB function so that doesn't require admin, just context.
b) provide a different DB function that doesn't require admin, and is called by REST API handler
c) new REST API/extension to get hosts that allows non-admin
d) elevate context in REST API handler before calling the DB function


In general i think a) is the right approach here. The checking for adminness at the db layer is
limited and we are already checking at the api layer so we should move away from doing it at all.

The short-term fix might be d) though since removing the admin checks will require auditing to
make sure we don't accidentally allow something that we shouldn't.

Vish



- Brant
_______________________________________________
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/20130425/82e8282f/attachment.html>