[openstack-dev] [nova] Non-Admin user can show deleted instances using changes-since parameter when calling list API
Zhenyu Zheng
zhengzhenyulixi at gmail.com
Fri Mar 4 03:14:11 UTC 2016
Hm, I found out the reason:
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/servers.py#L1139-L1145
here we filtered out parameters like "deleted", and that's why the API
behavior is like above mentioned.
So should we simple add "deleted" to the tuple or a microversion is needed?
On Fri, Mar 4, 2016 at 10:27 AM, Zhenyu Zheng <zhengzhenyulixi at gmail.com>
wrote:
> Anyway, I updated the bug report:
> https://bugs.launchpad.net/nova/+bug/1552071
>
> and I will start to working on the bug first.
>
> On Fri, Mar 4, 2016 at 9:29 AM, Zhenyu Zheng <zhengzhenyulixi at gmail.com>
> wrote:
>
>> Yes, so you are suggest fixing the return data of non-admin user use
>> 'nova list --deleted' but leave non-admin using 'nova list
>> --status=deleted' as is. Or it would be better to also submit a BP for next
>> cycle to add support for non-admin using '--status=deleted' with
>> microversions. Because in my opinion, if we allow non-admin use "nova list
>> --deleted", there will be no reason for us to limit the use of
>> "--status=deleted".
>>
>> On Fri, Mar 4, 2016 at 12:37 AM, Matt Riedemann <
>> mriedem at linux.vnet.ibm.com> wrote:
>>
>>>
>>>
>>> On 3/3/2016 10:02 AM, Matt Riedemann wrote:
>>>
>>>>
>>>>
>>>> On 3/3/2016 2:55 AM, Zhenyu Zheng wrote:
>>>>
>>>>> Yes, I agree with you guys, I'm also OK for non-admin users to list
>>>>> their own instances no matter what status they are.
>>>>>
>>>>> My question is this:
>>>>> I have done some tests, yet we have 2 different ways to list deleted
>>>>> instances (not counting using changes-since):
>>>>>
>>>>> 1.
>>>>> "GET
>>>>> /v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/detail?status=deleted
>>>>> HTTP/1.1"
>>>>> (nova list --status deleted in CLI)
>>>>> 2. REQ: curl -g -i -X GET
>>>>>
>>>>> http://10.229.45.17:8774/v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/detail?deleted=True
>>>>> (nova
>>>>> list --deleted in CLI)
>>>>>
>>>>> for admin user, we can all get deleted instances(after the fix of
>>>>> Matt's
>>>>> patch).
>>>>>
>>>>> But for non-admin users, #1 is restricted here:
>>>>>
>>>>> https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/servers.py#n350
>>>>>
>>>>> and it will return 403 error:
>>>>> RESP BODY: {"forbidden": {"message": "Only administrators may list
>>>>> deleted instances", "code": 403}}
>>>>>
>>>>
>>>> This is part of the API so if we were going to allow non-admins to query
>>>> for deleted servers using status=deleted, it would have to be a
>>>> microversion change. [1] I could also see that being policy-driven.
>>>>
>>>> It does seem odd and inconsistent though that non-admins can't query
>>>> with status=deleted but they can query with deleted=True in the query
>>>> options.
>>>>
>>>>
>>>>> and for #2 it will strangely return servers that are not in deleted
>>>>> status:
>>>>>
>>>>
>>>> This seems like a bug. I tried looking for something obvious in the code
>>>> but I'm not seeing the issue, I'd suspect something down in the DB API
>>>> code that's doing the filtering.
>>>>
>>>>
>>>>> DEBUG (connectionpool:387) "GET
>>>>> /v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/detail?deleted=True
>>>>> HTTP/1.1" 200 3361
>>>>> DEBUG (session:235) RESP: [200] Content-Length: 3361
>>>>> X-Compute-Request-Id: req-bd073750-982a-4ef7-864a-a5db03e59a68 Vary:
>>>>> X-OpenStack-Nova-API-Version Connection: keep-alive
>>>>> X-Openstack-Nova-Api-Version: 2.1 Date: Thu, 03 Mar 2016 08:43:17 GMT
>>>>> Content-Type: application/json
>>>>> RESP BODY: {"servers": [{"status": "ACTIVE", "updated":
>>>>> "2016-02-29T06:24:16Z", "hostId":
>>>>> "56b12284bb4d1da6cbd066d15e17df252dac1f0dc6c81a74bf0634b7",
>>>>> "addresses":
>>>>> {"private": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:4f:1b:32",
>>>>> "version":
>>>>> 4, "addr": "10.0.0.14", "OS-EXT-IPS:type": "fixed"},
>>>>> {"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:4f:1b:32", "version": 6, "addr":
>>>>> "fdb7:5d7b:6dcd:0:f816:3eff:fe4f:1b32", "OS-EXT-IPS:type": "fixed"}]},
>>>>> "links": [{"href":
>>>>> "
>>>>> http://10.229.45.17:8774/v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/ee8907c7-0730-4051-8426-64be44300e70
>>>>> ",
>>>>>
>>>>> "rel": "self"}, {"href":
>>>>> "
>>>>> http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/servers/ee8907c7-0730-4051-8426-64be44300e70
>>>>> ",
>>>>>
>>>>> "rel": "bookmark"}], "key_name": null, "image": {"id":
>>>>> "6455625c-a68d-4bd3-ac2e-07382ac5cbf4", "links": [{"href":
>>>>> "
>>>>> http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/images/6455625c-a68d-4bd3-ac2e-07382ac5cbf4
>>>>> ",
>>>>>
>>>>> "rel": "bookmark"}]}, "OS-EXT-STS:task_state": null,
>>>>> "OS-EXT-STS:vm_state": "active", "OS-SRV-USG:launched_at":
>>>>> "2016-02-29T06:24:16.000000", "flavor": {"id": "1", "links": [{"href":
>>>>> "http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/flavors/1",
>>>>> "rel": "bookmark"}]}, "id": "ee8907c7-0730-4051-8426-64be44300e70",
>>>>> "security_groups": [{"name": "default"}], "OS-SRV-USG:terminated_at":
>>>>> null, "OS-EXT-AZ:availability_zone": "nova", "user_id":
>>>>> "da935c024dc1444abb7b32390eac4e0b", "name": "test_inject", "created":
>>>>> "2016-02-29T06:24:08Z", "tenant_id":
>>>>> "62bfb653eb0d4d5cabdf635dd8181313",
>>>>> "OS-DCF:diskConfig": "MANUAL", "os-extended-volumes:volumes_attached":
>>>>> [], "accessIPv4": "", "accessIPv6": "", "progress": 0,
>>>>> "OS-EXT-STS:power_state": 1, "config_drive": "True", "metadata": {}},
>>>>> {"status": "ACTIVE", "updated": "2016-02-29T06:21:22Z", "hostId":
>>>>> "56b12284bb4d1da6cbd066d15e17df252dac1f0dc6c81a74bf0634b7",
>>>>> "addresses":
>>>>> {"private": [{"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:63:b0:12",
>>>>> "version":
>>>>> 4, "addr": "10.0.0.13", "OS-EXT-IPS:type": "fixed"},
>>>>> {"OS-EXT-IPS-MAC:mac_addr": "fa:16:3e:63:b0:12", "version": 6, "addr":
>>>>> "fdb7:5d7b:6dcd:0:f816:3eff:fe63:b012", "OS-EXT-IPS:type": "fixed"}]},
>>>>> "links": [{"href":
>>>>> "
>>>>> http://10.229.45.17:8774/v2.1/62bfb653eb0d4d5cabdf635dd8181313/servers/40bab05f-0692-43df-a8a9-e7c0d58a73bd
>>>>> ",
>>>>>
>>>>> "rel": "self"}, {"href":
>>>>> "
>>>>> http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/servers/40bab05f-0692-43df-a8a9-e7c0d58a73bd
>>>>> ",
>>>>>
>>>>> "rel": "bookmark"}], "key_name": null, "image": {"id":
>>>>> "6455625c-a68d-4bd3-ac2e-07382ac5cbf4", "links": [{"href":
>>>>> "
>>>>> http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/images/6455625c-a68d-4bd3-ac2e-07382ac5cbf4
>>>>> ",
>>>>>
>>>>> "rel": "bookmark"}]}, "OS-EXT-STS:task_state": null,
>>>>> "OS-EXT-STS:vm_state": "active", "OS-SRV-USG:launched_at":
>>>>> "2016-02-29T06:21:22.000000", "flavor": {"id": "1", "links": [{"href":
>>>>> "http://10.229.45.17:8774/62bfb653eb0d4d5cabdf635dd8181313/flavors/1",
>>>>> "rel": "bookmark"}]}, "id": "40bab05f-0692-43df-a8a9-e7c0d58a73bd",
>>>>> "security_groups": [{"name": "default"}], "OS-SRV-USG:terminated_at":
>>>>> null, "OS-EXT-AZ:availability_zone": "nova", "user_id":
>>>>> "da935c024dc1444abb7b32390eac4e0b", "name": "test_inject", "created":
>>>>> "2016-02-29T06:19:51Z", "tenant_id":
>>>>> "62bfb653eb0d4d5cabdf635dd8181313",
>>>>> "OS-DCF:diskConfig": "MANUAL", "os-extended-volumes:volumes_attached":
>>>>> [], "accessIPv4": "", "accessIPv6": "", "progress": 0,
>>>>> "OS-EXT-STS:power_state": 1, "config_drive": "True", "metadata": {}}]}
>>>>>
>>>>> I think this is obviously not consistent, I think we can decide what
>>>>> the
>>>>> behavior should be and make them consistent?
>>>>>
>>>>> Yours,
>>>>>
>>>>> Kevin
>>>>>
>>>>> On Thu, Mar 3, 2016 at 3:59 PM, Alex Xu <soulxu at gmail.com
>>>>> <mailto:soulxu at gmail.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> 2016-03-03 2:11 GMT+08:00 Matt Riedemann <
>>>>> mriedem at linux.vnet.ibm.com
>>>>> <mailto:mriedem at linux.vnet.ibm.com>>:
>>>>>
>>>>>
>>>>>
>>>>> On 3/2/2016 3:02 AM, Zhenyu Zheng wrote:
>>>>>
>>>>> Hi, Nova,
>>>>>
>>>>> While I'm working on add "changes-since" parameter support
>>>>> for
>>>>> python-novaclient "list" CLI.
>>>>>
>>>>> I realized that non-admin can list all deleted instances
>>>>> using
>>>>> "changes-since" parameter. This is reasonable in some
>>>>> level,
>>>>> as delete
>>>>> is an update to instances. But as we have a limitation that
>>>>> when list
>>>>> instances, deleted parameter is only allowed for admin
>>>>> users.
>>>>>
>>>>> This will lead to inconsistent to the rule of show deleted
>>>>> instances, as
>>>>> we limit the list of deleted instances to admin only, but
>>>>> non-admin can
>>>>> get the information using changes-since.
>>>>>
>>>>> Should we fix this?
>>>>>
>>>>> https://bugs.launchpad.net/nova/+bug/1552071
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Kevin Zheng
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> OpenStack Development Mailing List (not for usage
>>>>> questions)
>>>>> Unsubscribe:
>>>>>
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>> Unless I'm missing some use case, I think that listing
>>>>> instances
>>>>> for non-admins should be restricted to the instances they own,
>>>>> regardless of whether or not they are deleted, period.
>>>>>
>>>>>
>>>>> agree with this. I didn't see a problem showing the deleted
>>>>> instance
>>>>> for non-admins.
>>>>>
>>>>>
>>>>> As for listing deleting instances as an admin, that was broken
>>>>> with the 2.16 microversion and there is a fix here:
>>>>>
>>>>> https://review.openstack.org/#/c/283820/
>>>>>
>>>>> --
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Matt Riedemann
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>
>>>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>>>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>>
>>>>> <http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> __________________________________________________________________________
>>>>>
>>>>> OpenStack Development Mailing List (not for usage questions)
>>>>> Unsubscribe:
>>>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>> [1]
>>>>
>>>> https://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/servers.py?id=3a0e5f985fdd4b067d68450360cf62d57e82ecb2#n355
>>>>
>>>>
>>>>
>>> I confirmed what you're seeing [1]. A non-admin can use `nova list
>>> --deleted` and it's not an error but non-deleted instances are returned.
>>> But a non-admin can't use `nova list --status=deleted` because only admins
>>> can perform that operation since the REST API code explicitly checks the
>>> context.
>>>
>>> [1] https://gist.github.com/mriedem/1299a15007e413ff646a
>>>
>>>
>>> --
>>>
>>> Thanks,
>>>
>>> Matt Riedemann
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> 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/20160304/804a6ab3/attachment.html>
More information about the OpenStack-dev
mailing list