glance /v1.0/images does not return reasonable results

[Scott Devoid]

This may not be a bug, per se. What is returned from the basic GET request of "v1/images/detail" does not make sense.

Glance appears to only query for public images. [1] Indeed, adding a "&is_public=False" results in private images being shown. However, in this case it shows *all* private images, not just the images that are part of my tenant. Furthermore, I would expect the basic query to return images for which either (a) my tenant has access to or (b) I personally have access to. Neither of these cases appear to be queried in the default request.

[1] http://paste.openstack.org/show/54544/

[Stuart McLaren (stuart-mclaren)]

For anyone looking at this, the expected v1 behaviour is documented here:

http://docs.openstack.org/developer/glance/glanceapi.html (search for is_public=PUBLIC)

and note that " Use of the is_public parameter is restricted to admin users. For all other users it will be ignored.".

Scott, can you describe your installation? What release are you running? Do you have keystone enabled etc? Can you reproduce this on devstack? Thanks.

[Scott Devoid (scott-devoid)]

So the only note I see on expected behavior in the default case is: "We want to see a list of available images that the authenticated user has access to. This includes images owned by the user, images shared with the user and public images." That is a reasonable standard. What we have then, are results that do not match expectations.

So about my setup:
- OpenStack Havana build running on Ubuntu (using the Ubuntu Cloud Archive packages).
- Keystone is running and Glance is talking to Keystone.
- Policy.json file is as follows:
{
    "context_is_admin": "role:admin",
    "default": "",
    "manage_image_cache": "role:admin"
}

Tenants and Roles:
- Two tenants, "service" and "admin".
- Two roles, "admin" and "_member_"

Users:
- A glance user in the service tenant (with the admin role).
- A root user in the admin tenant with the admin role.
- A test user in the admin tenant with the _member_ role.

Behavior:
$ glance image-create
# Creates a "queued" blank image, see https://bugs.launchpad.net/python-glanceclient/+bug/1134463 and https://bugs.launchpad.net/python-glanceclient/+bug/1184965

# As "root"
$ glance image-create --name=Test --disk-format=qcow2 --container-format=bare < disk.img
# Create a private image with no owner properties, see https://bugs.launchpad.net/python-glanceclient/+bug/1258285

# Still as "root"
$ glance image-create --name=Test2 --owner=<admin-tenant-uuid> ...
# Creates a private image with correct owner uuid

$ glance image-list

# Empty, since both are private

$ glance image-list --is-public=False
+--------------------------------------+--------------+-------------+------------------+----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+--------------------------------------+--------------+-------------+------------------+----------+--------+
| 6edb0469-b5e9-444b-96d5-d6a679b7e6ed | | | | | queued |
| 17562c8d-3fed-438a-b49e-40ff19d86378 | Test | qcow2 | bare | 13147648 | active |
| f0d4b7f3-645b-44a5-8495-5e18e1bc41a9 | Test | qcow2 | bare | 13147648 | active |
+--------------------------------------+--------------+-------------+------------------+----------+--------+

# As "test"
$ glance image-list

# Empty, as expcted.

# Still as "test"
$ glance image-list --is-public=False
+--------------------------------------+--------------+-------------+------------------+----------+--------+
| ID | Name | Disk Format | Container Format | Size | Status |
+--------------------------------------+--------------+-------------+------------------+----------+--------+
| 6edb0469-b5e9-444b-96d5-d6a679b7e6ed | | | | | queued |
| 17562c8d-3fed-438a-b49e-40ff19d86378 | Test | qcow2 | bare | 13147648 | active |
| f0d4b7f3-645b-44a5-8495-5e18e1bc41a9 | Test | qcow2 | bare | 13147648 | active |
+--------------------------------------+--------------+-------------+------------------+----------+--------+

So wrong on several counts.

[Gabriel Assis Bezerra (gabriel-bezerra)]

The same problem happens here. In addition, only the same public images of glance image-list appear in Horizon's image list.

I've followed this guide to install all the OpenStack services: http://docs.openstack.org/havana/install-guide/install/apt/content/glance-install.html.

[Gabriel Assis Bezerra (gabriel-bezerra)]

The bug https://bugs.launchpad.net/glance/+bug/1245865 seems to be related to this one.

[Mark Washenberger (markwash)]

I need help trying to reproduce this. I think there are two clear avenues. One would be to try it out in devstack, another is to mess around with the visibility test in glance/tests/integration/legacy_functional in the visibility test for the v1 api.

[Scott Devoid (scott-devoid)]

I wasn't able replicate the issue in devstack as of last night. If you
could suggest some configuration points that could be causing the problem,
I can investigate on our system.

On Tue, Jan 14, 2014 at 3:48 PM, Mark Washenberger <
<email address hidden>> wrote:

> I need help trying to reproduce this. I think there are two clear
> avenues. One would be to try it out in devstack, another is to mess
> around with the visibility test in
> glance/tests/integration/legacy_functional in the visibility test for
> the v1 api.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1258342
>
> Title:
> glance /v1.0/images does not return reasonable results
>
> Status in OpenStack Image Registry and Delivery Service (Glance):
> Confirmed
>
> Bug description:
> This may not be a bug, per se. What is returned from the basic GET
> request of "v1/images/detail" does not make sense.
>
> Glance appears to only query for public images. [1] Indeed, adding a
> "&is_public=False" results in private images being shown. However, in
> this case it shows *all* private images, not just the images that are
> part of my tenant. Furthermore, I would expect the basic query to
> return images for which either (a) my tenant has access to or (b) I
> personally have access to. Neither of these cases appear to be queried
> in the default request.
>
> [1] http://paste.openstack.org/show/54544/
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/glance/+bug/1258342/+subscriptions
>

[Mark Washenberger (markwash)]

I'm wondering now about your auth context configuration. What setting are you using for "flavor" in glance-api.conf?

[Mark Washenberger (markwash)]

A note on https://bugs.launchpad.net/glance/+bug/1245865 suggests this may be related to the client version as well. What client version are you running?

[Scott Devoid (scott-devoid)]

"keystone"

[Scott Devoid (scott-devoid)]

0.11.0

---------- Forwarded message ----------
From: Mark Washenberger <email address hidden>
Date: Tue, Jan 14, 2014 at 4:48 PM
Subject: [Bug 1258342] Re: glance /v1.0/images does not return reasonable
results
To: <email address hidden>

A note on https://bugs.launchpad.net/glance/+bug/1245865 suggests this
may be related to the client version as well. What client version are
you running?

--
You received this bug notification because you are subscribed to the bug
report.
https://bugs.launchpad.net/bugs/1258342

Title:
  glance /v1.0/images does not return reasonable results

Status in OpenStack Image Registry and Delivery Service (Glance):
  Confirmed

Bug description:
  This may not be a bug, per se. What is returned from the basic GET
  request of "v1/images/detail" does not make sense.

  Glance appears to only query for public images. [1] Indeed, adding a
  "&is_public=False" results in private images being shown. However, in
  this case it shows *all* private images, not just the images that are
  part of my tenant. Furthermore, I would expect the basic query to
  return images for which either (a) my tenant has access to or (b) I
  personally have access to. Neither of these cases appear to be queried
  in the default request.

  [1] http://paste.openstack.org/show/54544/

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1258342/+subscriptions

[Mark Washenberger (markwash)]

Scott,

Thanks for your quick responses! Can you give the latest glanceclient a whirl? It sounds like there may be an update already in ubuntu (0.12.0.9 or later?) but if not you can get it from pypi and install it in a virtual environment. I'm sure you already know how to do that, but just to save on round trips in case you are not familiar:

virtualenv testbug
pip install python-glanceclient
glance <options as usual>

[Mark Washenberger (markwash)]

My brain is still a little bit tickled here because somehow regular users still seem to be getting treated as admin. . .

[Scott Devoid (scott-devoid)]

Ok, yes we are still seeing issues on several counts with 0.12.0.
http://paste.openstack.org/show/61318/

- glanceclient does not use OS_TENANT_NAME nor OS_USERNAME as owner of image if no alternatives are supplied.
- Listing images will not show private images where OWNER == OS_USERNAME nor OS_TENANT_NAME.

- It is possible to create images with owner = non-existant user or tenant.
- Passing in the tenant name or username to --owner flag results in that string as the owner, not a keystone UUID.

Seriously this is VERY BAD. I'm inclined to raise this as a security issue if it can be replicated.

[Scott Devoid (scott-devoid)]

Oh, I'm heading home for the day, but I'll be on #openstack tomorrow after 10AM CST.

[Joe T (joe-topjian-v)]

I can confirm all points that Scott has made. Some of the details are described here:

http://lists.openstack.org/pipermail/openstack/2014-January/004808.html

[Mark Washenberger (markwash)]

Hi Joe,

In your message, you say "In a fresh Ubuntu 12.04 Havana environment," what does that mean exactly? How can I reproduce this?

It doesn't seem to be a software problem (at least not at the first order) because I cannot reproduce the issue with just openstack components. So to track this down a developer is going to need a bit more detail on the environment used to reproduce it.

Thanks!

[Joe T (joe-topjian-v)]

Ah! I figured it out!

Mark, what I meant was that I was able to recreate this issue using a clean Ubuntu 12.04 installation and by following the installation instructions at docs.openstack.org.

However...

I began writing a bash script that would allow you to recreate the environment and in the process I noticed that

flavor=keystone

was never set in any of the Glance configuration files.

Basically there was no auth going on which explains all of the issues. I mean... who remembers to read until the very end of the file? =)

So my issue is resolved. I'm curious if Scott had the same typo.

Joe

[Joe T (joe-topjian-v)]

One more note: Scott, if you're still having issues, would you be able to try creating a bash script to produce the environment like I was doing? I'd be happy to take a look as well.

[Mark Washenberger (markwash)]

Thanks Joe.

Scott, I'm curious if its the same reason for you, or if there is some other reason why auth is apparently not happening.

[Erno Kuvaja (jokke)]

So can this be reproduced and if so, how? By the looks of it, if authentication is used there is no issue.

[Erno Kuvaja (jokke)]

Two months without activity, closing.