
<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 12, 2013, at 3:22 PM, Brant Knudson <<a href="mailto:blk@acm.org">blk@acm.org</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br>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).<br>

<br>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.)<br>

<br>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.)<br>

<br>I opened a bug: <a href="https://bugs.launchpad.net/nova/+bug/1168488">https://bugs.launchpad.net/nova/+bug/1168488</a><br><br>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.<br>

<br>Potential approaches to fixing, at least compute_extension:hosts:<br>a) change DB function so that doesn't require admin, just context.<br>b) provide a different DB function that doesn't require admin, and is called by REST API handler<br>

c) new REST API/extension to get hosts that allows non-admin<br>d) elevate context in REST API handler before calling the DB function<br></div></blockquote><div><br></div><div><br></div>In general i think a) is the right approach here. The checking for adminness at the db layer is</div><div>limited and we are already checking at the api layer so we should move away from doing it at all.</div><div><br></div><div>The short-term fix might be d) though since removing the admin checks will require auditing to</div><div>make sure we don't accidentally allow something that we shouldn't.</div><div><br></div><div>Vish</div><div><br><blockquote type="cite"><div dir="ltr"><br>- Brant<br><br></div>

_______________________________________________<br>OpenStack-dev mailing list<br><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev<br></blockquote></div><br></body></html>