Bug 1497662
| Summary: | Glance doesn't send correctly authorization request to Oslo policy | ||
|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Bertrand <brault> |
| Component: | openstack-glance | Assignee: | Cyril Roelandt <cyril> |
| Status: | CLOSED ERRATA | QA Contact: | Mike Abrams <mabrams> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 10.0 (Newton) | CC: | brault, cyril, eglynn, fpercoco, marjones, mlopes, pgrist, ruan.he, srevivo, tshefi, vstinner |
| Target Milestone: | z7 | Keywords: | Triaged, ZStream |
| Target Release: | 10.0 (Newton) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| URL: | https://bugs.launchpad.net/glance/+bug/1720354 | ||
| Whiteboard: | |||
| Fixed In Version: | openstack-glance-13.0.0-2.el7ost | Doc Type: | Bug Fix |
| Doc Text: |
Prior to this update, when using custom Oslo policies, certain image-related operations (such as creation/deletion) could result in a crash. With this update, glance allows users to use such custom policies. As a result, you should not observe further crashes when using custom Oslo policies.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-02-27 16:22:11 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1403461 | ||
I can reproduce this issue on devstack. Looking at the code from oslo_policy/_checks.py, two things come to mind: 1) copy.deepcopy is called on a glance.api.policy.ImageTarget, and this class does not seem to define a __deepcopy__ method, which we might want to add since deep copying seems tricky. 2) the keys() method is called on the glance.api.policy.ImageTarget object, and that is definitely not going to work, since this is not a dict, and no keys() method is defined. This leads me to believe that Glance is not really supposed to send an ImageTarget object to oslo.policy: it should probably send a dict. I do not really know how the dict should be formed though (what keys, what values). @Bertrand: do you know what the dict is supposed to look like? @Victor: same question, since you work on Oslo and might know what is expected here :) > @Victor: same question, since you work on Oslo and might know what is expected here :) Enforcer.enforce() expects a Python dictionary ("dict") for the target parameter: https://docs.openstack.org/oslo.policy/latest/reference/api/oslo_policy.policy.html#oslo_policy.policy.Enforcer.enforce Glance policy enforce() also expects a dictionary for the target parameter: https://github.com/openstack/glance/blob/master/glance/api/policy.py#L54 The target parameter of the policy was filled by this Glance spec: https://specs.openstack.org/openstack/glance-specs/specs/kilo/pass-targets-to-policy-enforcer.html It seems like Glance doesn't pass a Python dictionary, but a "dict-like" object: ImageTarget which only implements __getitem__(). It's a thin mapping proxy to make 2 conversions (key image_id => id, value: look into extra_properties if needed). copy.deepcopy(target) must work. You may just implement a __deepcopy__() method: https://specs.openstack.org/openstack/glance-specs/specs/kilo/pass-targets-to-policy-enforcer.html You might also extend ImageTarget API to implement the full dict API, by inheriting from collections.abc.Mapping, but I'm not sure that it's needed. Bertrand: at https://bugzilla.redhat.com/show_bug.cgi?id=1403461#c11 you wrote that this bug should be targeted to OSP 13, but right now, it's targeted to OSP 10, and Cyril wrote a fix for OSP 10. Can you please confirm that the customer is waiting for OSP 13? (In reply to Victor Stinner from comment #3) > Bertrand: at https://bugzilla.redhat.com/show_bug.cgi?id=1403461#c11 you > wrote that this bug should be targeted to OSP 13, but right now, it's > targeted to OSP 10, and Cyril wrote a fix for OSP 10. Can you please confirm > that the customer is waiting for OSP 13? To be fair, the fix is available upstream, so if it is needed for OSP13, it will get there at some point :) (In reply to Victor Stinner from comment #3) > Bertrand: at https://bugzilla.redhat.com/show_bug.cgi?id=1403461#c11 you > wrote that this bug should be targeted to OSP 13, but right now, it's > targeted to OSP 10, and Cyril wrote a fix for OSP 10. Can you please confirm > that the customer is waiting for OSP 13? The external PDP Hook feature is planned to be used in prod for OSP 13 with partner conducting testing around OSP10 as well. @Cyril: The status should be POST, not MODIFIED, since a package is available, no? > @Cyril: The status should be POST, not MODIFIED, since a package is available, no?
Oops, I'm wrong, POST is the right status ;-)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:0359 |
Description of problem: We have an OpenStack installed with Keystone, Nova and Glance. In /etc/glance/policy.json, we have modified the following lines to test the http_check function of Oslo policy: ... "add_image": "http://moon:8081/authz/wrapper", "delete_image": "http://moon:8081/authz/wrapper", "get_image": "http://moon:8081/authz/wrapper", "get_images": "http://moon:8081/authz/wrapper", "modify_image": "http://moon:8081/authz/wrapper", ... Then, when we run: $ openstack image list +--------------------------------------+--------+--------+ | ID | Name | Status | +--------------------------------------+--------+--------+ | 6e31cdd2-4968-4a80-aebc-fcdd6f213091 | cirros | active | +--------------------------------------+--------+--------+ with no problem, but if we run: $ openstack image create --disk-format qcow2 --file /vagrant/cirros-0.3.5-x86_64-disk.img --container-format bare cirros4 400 Bad Request cannot deepcopy this pattern object (HTTP 400) The Oslo_Policy code doesn't raise an error but stop when trying to deepcopying the target variable in oslo.policy/oslo.policy/oslo_policy/_checks.py (line ~241) and we have the following event in Glance API logs: 2017-09-25 12:48:16.044 16600 DEBUG oslo_policy._cache_handler [req-e98eef44-d01b-401f-8e69-c78adf5310d3 - - - - -] Reloading cached file /etc/glance/policy.json read_cached_file /usr/local/lib/python2.7/dist-packages/oslo_policy/_cache_handler.py:40 2017-09-25 12:48:16.047 16600 DEBUG oslo_policy.policy [req-e98eef44-d01b-401f-8e69-c78adf5310d3 - - - - -] Reloaded policy file: /etc/glance/policy.json _load_policy_file /usr/local/lib/python2.7/dist-packages/oslo_policy/policy.py:682 2017-09-25 12:48:16.075 16600 DEBUG glance.api.v2.images [req-e98eef44-d01b-401f-8e69-c78adf5310d3 - - - - -] cannot deepcopy this pattern object create /usr/lib/python2.7/dist-packages/glance/api/v2/images.py:85 2017-09-25 12:48:16.084 16600 INFO eventlet.wsgi.server [req-e98eef44-d01b-401f-8e69-c78adf5310d3 - - - - -] 127.0.0.1 - - [25/Sep/2017 12:48:16] "POST /v2/images HTTP/1.1" 400 273 0.053245 An other problem is that we have not enough information in the target variable (in oslo.policy/oslo.policy/oslo_policy/_checks.py). Because most of the information have the 'object' type, they are deleted from the temp_target variable (line ~244). We believe that this is due to the Glance part since it doesn't well prepare the authorization request (body) to Oslo policy.