Images in inconsistent state when calls to registry fail during image deletion

1. I agree, the image deletion operation should be atomic.

2. Image data left behind means there is a potential risk of filling up storage quota and resulting into a DoS; be mindful that it's a denial of service but NOT a exploit as it is dependent on the operators' failure scenarios of g-api <-> reg communication.

3. The original description has information related to failure scenarios for only v1. So, a check is needed for the v2 as applicable.

I am marking this as a public security as we need to let the operators know of such failure scenarios. There's no exploit at the user level so this was never a candidate for private security.

Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.

Can user make the image deletion to fail ? e.g., can this be abused trivially ?

Nikhil,

Security flag should not be used just to inform operators for possible failure conditions.

Tristan,
IMO this bug has nothing to do with security as there is no attack vector here.

Thanks Erno, I've removed the OSSA task

The history of code around this bug goes back to defect:
https://bugs.launchpad.net/glance/+bug/1065187
because of security issue the code was modified as follows:
step 1: Update image metadata with status = deleted
step 2: mark image in db as deleted=true and deleted_at = time
step 3: delete the image from backend
as per comment: https://bugs.launchpad.net/glance/+bug/1065187/comments/2

Later there was a bug filed https://bugs.launchpad.net/glance/+bug/1276142
Here they claimed, if deleting image from backend failed then
users can not use glance image-delete command to clean up the orphan image in backend.
For this purpose code was changed as follows:
step 1: Update image metadata with status = deleted
step 2: delete the image from backend
step 3: mark image in db as deleted=true and deleted_at = time

Now this bug points that what if, image metadata delete from db fails..

On closely looking at v2 api flow:
glance v2 checks the authorization with policy.json to allow delete action
deletes the image from backend
mark image in db as deleted=true and deleted_at = time

To maintain consistency between v1 and v2,
keeping v2 flow as reference in v1 we will do following:
step 1: try image metadata update status=[current image status]
if the above update fails that means user is not allowed to update the image and hence delete action will error
step 2: Then delete the image from backend
step 3: if, its successful, set the image status=pending delete/deleted, deleted=true and deleted_at=time.now()

Alternatively, we could delete the image metadata from db first so that the image is not at all usable
and then try deleting from backend, if, backend fails there can be an error message specifying what to do.

Looking forward to suggestions on this, so that I can proceed with the fix.

Fix proposed to branch: master
Review: https://review.openstack.org/539495

v1 API is deprecated.

Change abandoned by "Cyril Roelandt <email address hidden>" on branch: master
Review: https://review.opendev.org/c/openstack/glance/+/539495
Reason: The bug has been marked as invalid, so this is not required