Policy.json get_service_profiles says admin_only but non-admin users can access api

[jessegler]

Policy.json has these two lines:
    "create_service_profile": "rule:admin_only",
    "get_service_profiles": "rule:admin_only",

However get_service_profiles can be accessed without error by non-admin user:

$ export OS_USERNAME=demo
$ openstack token issue
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| expires | 2018-08-28T22:11:10+0000 |
| id | gAAAAABbhbpuuY6N3_jsujbYhGkotgjoVwlwynqVJ_Uot6RrvJtzqoL0vv74hJewGlx4WZB81ddK8J7hYUqltKtV4iN8VbvEvMuVIl8BPgkWHlDcJPC_SF-KYda6NMweldqkYcL65nc26n2Rzg5PhYGcCvEwIfyXLsnLCgJYcW09Se_utmqCXbM |
| project_id | 28f7717697d34265accbd0b348ee1e51 |
| user_id | 6465999184924e9d9fec2618b15ab277 |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
devstack@devstack$ export MY_TOKEN=gAAAAABbhbpuuY6N3_jsujbYhGkotgjoVwlwynqVJ_Uot6RrvJtzqoL0vv74hJewGlx4WZB81ddK8J7hYUqltKtV4iN8VbvEvMuVIl8BPgkWHlDcJPC_SF-KYda6NMweldqkYcL65nc26n2Rzg5PhYGcCvEwIfyXLsnLCgJYcW09Se_utmqCXbM
devstack@devstack:/opt/stack/logs$ curl -H "X-Auth-Token: $MY_TOKEN" -X GET http://127.0.0.1:9696/v2.0/service_profiles{"service_profiles": []}

I would expect an error similar to create_service_profile because they have the same admin_only policy:

$ curl -H "X-Auth-Token: $MY_TOKEN" -X POST http://127.0.0.1:9696/v2.0/service_profiles -d '{ "service_profile": { "enabled": "true", "description": "Dummy profile", "metainfo" : "{'foo': 'bar'}"}}'
{"NeutronError": {"message": "rule:create_service_profile is disallowed by policy", "type": "PolicyNotAuthorized", "detail": ""}}

Please note, that despite not receiving an error, the non-admin user does get an empty list despite existing service_profiles:

$ export OS_USERNAME=admin
$ openstack token issue
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| expires | 2018-08-28T22:15:06+0000 |
| id | gAAAAABbhbtaMytoBFfviejpK5m7OnlusCnp1p_gExNtsaxAbfD1egn0ljOBb93uXjyPOE6bhMj0hcvDa2CE_o9odPBQmIgZKAtOq9-_OLGUvZbq4ACZAG1_DvLYBCPsB2X8qoD2cvRxPGQKbWdnviuos-nHdtkKnfdhYt6UWBCa3gm7dcvr0EE |
| project_id | 28f7717697d34265accbd0b348ee1e51 |
| user_id | e935d2593d404a86ba0f58c5a84c8ae2 |
+------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
$ export MY_TOKEN=gAAAAABbhbtaMytoBFfviejpK5m7OnlusCnp1p_gExNtsaxAbfD1egn0ljOBb93uXjyPOE6bhMj0hcvDa2CE_o9odPBQmIgZKAtOq9-_OLGUvZbq4ACZAG1_DvLYBCPsB2X8qoD2cvRxPGQKbWdnviuos-nHdtkKnfdhYt6UWBCa3gm7dcvr0EE

$ curl -H "X-Auth-Token: $MY_TOKEN" -X GET http://127.0.0.1:9696/v2.0/service_profiles{"service_profiles": [{"id": "a4e1544b-5296-46b8-bdb6-02f9d11eef2c", "enabled": true, "driver": "", "description": "Dummy profile", "metainfo": "{foo: bar}"}]}

[Lajos Katona (lajos-katona)]

The issues really there (I tried in devstack, everything is on master).

What I see is however that the policy rule enforcement works in a little tricky way for GET (perhaps for other operations as well, but I checked GET).

So let's see GET /agents, which is admin_only operation by policy.json:

$ grep get_agent /etc/neutron/policy.json
    "get_agent": "rule:admin_only",

1.) Let's see as tenant=admin, user=admin:
$ echo $OS_PROJECT_NAME ;echo $OS_TENANT_NAME ;echo $OS_USERNAME
admin
admin
admin

$ export MY_TOKEN=$(openstack token issue -c id -f value)

$ curl -H "X-Auth-Token: $MY_TOKEN" -X GET http://127.0.0.1:9696/v2.0/agents
{"agents": [{"binary": "neutron-openvswitch-agent"........},.....]}

2.) Let's see the same as project=demo, user=demo
$ echo $OS_PROJECT_NAME ;echo $OS_TENANT_NAME ;echo $OS_USERNAME
demo
demo
demo

$ export MY_TOKEN=$(openstack token issue -c id -f value)

$ curl -H "X-Auth-Token: $MY_TOKEN" -X GET http://127.0.0.1:9696/v2.0/agents
{"agents": []}

So the user really can't see the agents, which is allowed only for admin.
I am not sure/not qualified to tell what would be the good behaviour:
1) Give an exception to the user (like http403, and some text for it: "rule:delete_flavor is disallowed by policy....").
2) Or pretend to show something end give back an empty list, like it is now. I don't know the historical reasons, but these topics are the ones to chew by security guys.

[jessegler (je808k)]

Yup. I think this is a defect because there is no error returned at all. I think either a 403 forbidden or a 404 not found would be appropriate. GET requests for a single resource return 404 when the user doesn't have permission to view that resource.

I don't like that the user doesn't receive an error at all here. I think that's confusing, but you're right that it might be for security purposes.

[Lajos Katona (lajos-katona)]

I read some code for this problem:

# when listing resources it is possible that some items are restricted for the given user, but others are not (imagine network list, where there is the shared flag as well)
# so neutron server creates an empty list then
# go through the list of resources and check it against the policy and
# if it passes the policy check, append to the list, otherwise not.
# If all items on the list of resources failed the policy check an empty list will be returned, and from API point of view no error happened, so http200 will presented to the user, with an empty list in the body.
And it is hard to make a difference between "empty because there were no items to list" and "empty because the user has no right to see the list".

I check it to see if we can give the user some feedback, and let's see what others will think about it.

[OpenStack Infra (hudson-openstack)]

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

[Lajos Katona (lajos-katona)]

I uploaded a WIP patch (https://review.openstack.org/601270), check if it is something you miss please.
I would wait for the cores to have their opinion on this topic.

[Slawek Kaplonski (slaweq)]

IMO this is valid bug. If some call is in general forbidden for user, it should returns 403 instead of empty list with 200.

There are other cases when user wants e.g. get resource which don't belong to him. Then we should IMO return 404 instead of 403 to not show that such resource really exists even. And AFAIK it is like that now.
Also in case when e.g. user tries to do neutron net-list and there are only networks which don't belong to him, he should get 200 and empty list.

[Lajos Katona (lajos-katona)]

Thanks Slawek, I will continue with the WIP patch.

[Lajos Katona (lajos-katona)]

Some interesting things during my "research" (NOTE: all the commands/API calls below were executed after source openrc demo demo)

* The WIP patch (https://review.openstack.org/601270) seemed too easy, but solved the problem with agents for example. So GET v2.0/agents give back 401 and a body like this: {"NeutronError": {"message": "No resource could be found.", "detail": "", "type": "HTTPNotFound"}}

* but the same patch was not solving the same problem with ports for example:
** I changed policy.json to get_port:rule:admin_only
** The status code is 401 unauthorized, but the result is empty list.

The weirdest part:
Do the API call with show:
$ curl -H "X-Auth-Token: $MY_TOKEN" -X GET http://100.109.0.44:9696/v2.0/ports/3ded052c-ac26-4eec-9b7e-19ee143721a2
{"port": {"binding:vif_type": "unbound", ...., "security_groups": []}}
$ curl -I -H "X-Auth-Token: $MY_TOKEN" -X GET http://100.109.0.44:9696/v2.0/ports/3ded052c-ac26-4eec-9b7e-19ee143721a2
HTTP/1.1 404 Not Found

So by this the response header has the status code 404, but the body as well.

[Slawek Kaplonski (slaweq)]

This bug has had a related patch abandoned and has been automatically un-assigned due to inactivity. Please re-assign yourself if you are continuing work or adjust the state as appropriate if it is no longer valid.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Slawek Kaplonski (<email address hidden>) on branch: master
Review: https://review.openstack.org/601270
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.