yahoo-eng-team team mailing list archive

[Erno Kuvaja <1884587@xxxxxxxxxxxxxxxxxx>]

** Also affects: glance/victoria
   Importance: Undecided
       Status: In Progress

** Also affects: glance/ussuri
   Importance: Undecided
       Status: New

** Changed in: glance/ussuri
   Importance: Undecided => High

** Changed in: glance/victoria
   Importance: Undecided => High

-- 
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:
  In Progress
Status in Glance ussuri series:
  New
Status in Glance victoria series:
  In Progress

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