cinder store fails to update legacy images

Bug #2056179 reported by Rajat Dhasmana
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
glance_store
Fix Released
Undecided
Rajat Dhasmana

Bug Description

When trying to update legacy images in cinder store, we query cinder to get the volume and compare it's volume type with the one configured in glance. We do it for all configured cinder stores and if there is a match, we update the url from old format (cinder://<vol-id>) to the new format (cinder://<store-id>/<vol-id>).

The current workflow uses the user context's credentials to make the get volume request. This works if the user is admin since it has access to all volumes (or if the volume is stored in the user's project which is unlikely) but fails if a user A has access to project X and the volume is created by a user B in project Y as seen in the testing done here[1] when tempest creates it's own user and project and tries to upload it to glance. (in the background it creates an internal image-volume in the service project with the service user, 'cinder' here[2]).

Ideally the image-volumes should be stored in the service project and glance should use the service credentials (as defined in glance-api.conf) to access the volume. If the volume is stored in any other project, its susceptible to modifications by normal users which could corrupt the image.

[1] https://review.opendev.org/c/openstack/cinder/+/909847
[2] https://review.opendev.org/c/openstack/cinder/+/911004

Changed in glance-store:
status: New → In Progress
Changed in glance-store:
assignee: nobody → Rajat Dhasmana (whoami-rajat)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to glance_store (master)

Reviewed: https://review.opendev.org/c/openstack/glance_store/+/911005
Committed: https://opendev.org/openstack/glance_store/commit/c2b7b78d4ff55ea079ea6172241011edc68f5b23
Submitter: "Zuul (22348)"
Branch: master

commit c2b7b78d4ff55ea079ea6172241011edc68f5b23
Author: Rajat Dhasmana <email address hidden>
Date: Tue Mar 5 03:26:55 2024 +0530

    Use normal credentials for legacy image update

    When updating legacy images, currenly we use the user's
    context and elevate priviledges. However, we do not
    require admin priviledges for the cinder API calls.

    This patch removes the special case where we elevate
    priviledges as it wasn't doing anything rather avoiding
    us to use right credentials and failing to fetch volume
    in the right location because of wrong credentials.

    The correct credentials are either the service ones
    set in glance-api.conf file or the user context
    credentials, using which the Image-Volume was created.

    NOTE: When using cinder as glance backend and we want
    to perform optimized volume upload to image, one thing
    we should make sure is either using the context or the
    cinder credentials set in glance-api.conf file, it should
    match the following details on the cinder side (if we are
    using internal context to create clone of image-volumes):

    cinder_store_user_name = context.user_id/cinder_internal_tenant_user_id
    cinder_store_project_name = context.project_id/cinder_internal_tenant_project_id

    The cinder_internal_tenant_user_id and
    cinder_internal_tenant_project_id are set in the
    [DEFAULT] section of cinder.conf.

    This issue was first discovered when testing the new
    location APIs[1] where tempest creates a volume with
    cinder's internal context and glance uses wrong (user context)
    credentials to access it and failing with 404 not found.

    [1] https://review.opendev.org/c/openstack/cinder/+/909847

    Closes-Bug: #2056179
    Change-Id: I4f27a9800f239da8dbf29f4c028678df1f867664

Changed in glance-store:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/glance_store 4.8.0

This issue was fixed in the openstack/glance_store 4.8.0 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.