Bug 1497662 - Glance doesn't send correctly authorization request to Oslo policy
Summary: Glance doesn't send correctly authorization request to Oslo policy
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-glance
Version: 10.0 (Newton)
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: z7
: 10.0 (Newton)
Assignee: Cyril Roelandt
QA Contact: Mike Abrams
URL: https://bugs.launchpad.net/glance/+bu...
Whiteboard:
Depends On:
Blocks: 1403461
TreeView+ depends on / blocked
 
Reported: 2017-10-02 11:45 UTC by Bertrand
Modified: 2018-02-27 16:22 UTC (History)
11 users (show)

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.
Clone Of:
Environment:
Last Closed: 2018-02-27 16:22:11 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1720354 0 None None None 2017-10-04 18:39:57 UTC
OpenStack gerrit 512020 0 None None None 2017-10-27 14:53:54 UTC
Red Hat Product Errata RHBA-2018:0359 0 normal SHIPPED_LIVE openstack-glance bug fix advisory 2018-02-27 21:22:33 UTC

Description Bertrand 2017-10-02 11:45:33 UTC
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.

Comment 1 Cyril Roelandt 2017-10-03 19:51:14 UTC
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 :)

Comment 2 Victor Stinner 2017-10-04 12:53:21 UTC
> @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.

Comment 3 Victor Stinner 2017-12-01 14:09:37 UTC
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?

Comment 4 Cyril Roelandt 2017-12-04 10:40:47 UTC
(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 :)

Comment 5 Bertrand 2017-12-04 11:34:00 UTC
(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.

Comment 6 Victor Stinner 2017-12-21 21:59:05 UTC
@Cyril: The status should be POST, not MODIFIED, since a package is available, no?

Comment 7 Victor Stinner 2018-01-08 15:25:00 UTC
> @Cyril: The status should be POST, not MODIFIED, since a package is available, no?

Oops, I'm wrong, POST is the right status ;-)

Comment 15 errata-xmlrpc 2018-02-27 16:22:11 UTC
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


Note You need to log in before you can comment on or make changes to this bug.