host-list policy irrelevant

[Brant Knudson]

There are some compute REST APIs where the policy setting is irrelevant because they require admin. host-list is an example.

To recreate, start with devstack, set up so that you're running as demo user.

 $ export OS_USERNAME=demo
 $ export OS_PASSWORD=mypwd
 $ export OS_TENANT_NAME=demo
 $ export OS_AUTH_URL=http://localhost:5000/v2.0
 $ export OS_NO_CACHE=1

 # First try with the default policy:
 $ grep compute_extension:hosts /etc/nova/policy.json
    "compute_extension:hosts": "rule:admin_api",
 $ nova host-list
ERROR: Policy doesn't allow compute_extension:hosts to be performed. (HTTP 403) (Request-ID: req-b2b9408c-4498-4994-aee7-100cf6acf571)

 # Change policy so that anyone can view hosts:
 $ grep compute_extension:hosts /etc/nova/policy.json
    "compute_extension:hosts": "",
 $ nova host-list
 ERROR: User does not have admin privileges (HTTP 403) (Request-ID: req-48983c2e-784c-4bb5-82ac-6116a67f6fe1)

It was expected that since I configured the policy so that anyone could view hosts that a non-admin user could list hosts.

Nova should respect the policy that the admin configured and not force its own.

[Ivan-Zhu (ivan-zhu)]

This because there are @require_admin_context in /nova/db/sqlalchemy/api.py. Change policy.json just allow regular user can use this api, but in db level it also need admin privileges. I think these operation must be executed by admin user.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/26972

[Andrew Laski (alaski)]

For listing hosts I could see making that available to non-admins. There are some policies that may not ever make sense for a non-admin to perform, and I think it would be good to have a way to indicate that to a deployer so that they are not confused with a 403 when policies match up.

[Brant Knudson (blk-u)]

The review the the proposed change here https://review.openstack.org/26972 got some great comments, and it looks like the community would rather have the correct full change rather than the strategic one proposed.

From the comments on the review, it looks like the changes identified are:
1) Change the database function so that it doesn't require admin, then don't need to elevate context, but do need to do an audit to make sure not opening up a security hole.
2) Do more fine-grained policy checking for hosts, hypervisors, and whatever else could use this fix.
(tip: There's already a method for achieving that with an extra kwarg to the authorizer that most policies are using, like https://github.com/openstack/nova/blob/stable/grizzly/nova/api/openstack/compute/contrib/flavorextraspecs.py#L65.)

Maybe this work should be done as a blueprint rather than a bug.

I'm going to remove myself as the assignee, since I'm not currently working on it. I may make some time in the Havana timeframe, but marking it as available if someone else wants to take it on.

I'm going to abandon the other reviews.

[Brant Knudson (blk-u)]

Note that this also applies to the admin_actions extension, migrate and migrateLive are specifically a problem for us.

[Christopher Yeoh (cyeoh-0)]

This is getting handled as part of the process of bubbling up all of the policy checks to the API level - although targetted for the V3 API it will also affect the V2 API.

https://blueprints.launchpad.net/nova/+spec/v3-api-policy

So I'm closing this bug as it will be tracked through the blueprint instead.

[Matt Riedemann (mriedem)]

Should be handled here: https://review.openstack.org/#/c/150349/