yahoo-eng-team team mailing list archive

[Dan Smith <1884587@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

In testing the image import copy-to-store mechanism from Nova, I hit an
issue that seems clearly to be a bug. Scenario:

A user boots an instance from an image they have permission to see. Nova
uses their credentials to start an image import copy-to-store operation,
which succeeds:

"POST /v2/images/e6b1a7d0-ccd8-4be3-bef7-69c68fca4313/import HTTP/1.1" 202 211 0.481190
Task [888e97e5-496d-4b94-b530-218d633f866a] status changing from pending to processing

Note the 202 return code. My code polls for a $timeout period, waiting
for the image to either arrive at the new store, or be marked as error,
which never happens ($timeout=600s). The glance log shows (trace
truncated):

glance-api[14039]:   File "/opt/stack/glance/glance/async_/flows/api_image_import.py", line 481, in get_flow
glance-api[14039]:     stores if
glance-api[14039]:   File "/opt/stack/glance/glance/api/authorization.py", line 296, in forbidden_key
glance-api[14039]:     raise exception.Forbidden(message % key)
glance-api[14039]: glance.common.exception.Forbidden: You are not permitted to modify 'os_glance_importing_to_stores' on this image.

So apparently Nova is unable to use the user's credentials to initiate a
copy-to-store operation. That surprises me and I think it likely isn't
the access control we should be enforcing. However, if we're going to
reject the operation, we should reject it at the time the HTTP response
is sent, not later async, since we can check authorization right then
and there.

The problem in this case is that from the outside, I have no way of
knowing that the task fails subsequently. I receive a 202, which means I
should start polling for completion. The task fails to load/run and thus
can't update any status on the image, and I'm left to wait for 600s
before I give up.

So, at the very least, we're not checking the same set of permissions
during the HTTP POST call, and we should be. I also would tend to argue
that the user should be allowed to copy the image and not require an
admin to do it, perhaps with some additional policy element to control
that. However, I have to be able to determine when and when not to wait
for 600s.

** Affects: glance
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1884587

Title:
  image import copy-to-store API should reflect proper authorization

Status in Glance:
  New

Bug description:
  In testing the image import copy-to-store mechanism from Nova, I hit
  an issue that seems clearly to be a bug. Scenario:

  A user boots an instance from an image they have permission to see.
  Nova uses their credentials to start an image import copy-to-store
  operation, which succeeds:

  "POST /v2/images/e6b1a7d0-ccd8-4be3-bef7-69c68fca4313/import HTTP/1.1" 202 211 0.481190
  Task [888e97e5-496d-4b94-b530-218d633f866a] status changing from pending to processing

  Note the 202 return code. My code polls for a $timeout period, waiting
  for the image to either arrive at the new store, or be marked as
  error, which never happens ($timeout=600s). The glance log shows
  (trace truncated):

  glance-api[14039]:   File "/opt/stack/glance/glance/async_/flows/api_image_import.py", line 481, in get_flow
  glance-api[14039]:     stores if
  glance-api[14039]:   File "/opt/stack/glance/glance/api/authorization.py", line 296, in forbidden_key
  glance-api[14039]:     raise exception.Forbidden(message % key)
  glance-api[14039]: glance.common.exception.Forbidden: You are not permitted to modify 'os_glance_importing_to_stores' on this image.

  So apparently Nova is unable to use the user's credentials to initiate
  a copy-to-store operation. That surprises me and I think it likely
  isn't the access control we should be enforcing. However, if we're
  going to reject the operation, we should reject it at the time the
  HTTP response is sent, not later async, since we can check
  authorization right then and there.

  The problem in this case is that from the outside, I have no way of
  knowing that the task fails subsequently. I receive a 202, which means
  I should start polling for completion. The task fails to load/run and
  thus can't update any status on the image, and I'm left to wait for
  600s before I give up.

  So, at the very least, we're not checking the same set of permissions
  during the HTTP POST call, and we should be. I also would tend to
  argue that the user should be allowed to copy the image and not
  require an admin to do it, perhaps with some additional policy element
  to control that. However, I have to be able to determine when and when
  not to wait for 600s.

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