nova/releasenotes/notes/bug-1675791-snapshot-member-access-c40bba36606618f7.yaml
Matt Riedemann 35cc0f5e94 Share snapshot image membership with instance owner
When an admin creates a snapshot of another project owners
instance, either via the createImage API directly, or via the
shelve or createBackup APIs, the admin project is the owner
of the image and the owner of the instance (in another project)
cannot "see" the image. This is a problem, for example, if an
admin shelves a tenant user's server and then the user tries to
unshelve the server because the user will not have access to
get the shelved snapshot image.

This change fixes the problem by leveraging the sharing feature [1]
in the v2 image API. When a snapshot is created where the request
context project_id does not match the owner of the instance project_id,
the instance owner project_id is granted sharing access to the image.
By default, this means the instance owner (tenant user) can get the
image directly via the image ID if they know it, but otherwise the image
is not listed for the user to avoid spamming their image listing. In the
case of unshelve, the end user does not need to know the image ID since
it is stored in the instance system_metadata. Regardless, the user could
accept the pending image membership if they want to see the snapshot
show up when listing available images.

Note that while the non-admin project has access to the snapshot
image, they cannot delete it. For example, if the user tries to
delete or unshelve a shelved offloaded server, nova will try to
delete the snapshot image which will fail and log a warning since
the user does not own the image (the admin does). However, the
delete/unshelve operations will not fail because the image cannot
be deleted, which is an acceptable trade-off.

Due to some very old legacy virt driver code which started in the
libvirt driver and was copied to several other drivers, several virt
drivers had to be modified to not overwrite the "visibility=shared"
image property by passing "is_public=False" when uploading the image
data. There was no point in the virt drivers setting is_public=False
since the API already controls that. It does mean, however, that
the bug fix is not really in effect until both the API and compute
service code has this fix.

A functional test is added which depends on tracking the owner/member
values in the _FakeImageService fixture. Impacted unit tests are
updated accordingly.

[1] https://developer.openstack.org/api-ref/image/v2/index.html#sharing

Change-Id: If53bc8fa8ab4a8a9072061af7afed53fc12c97a5
Closes-Bug: #1675791
2019-02-08 18:06:27 -05:00

27 lines
1.2 KiB
YAML

---
fixes:
- |
`Bug 1675791`_ has been fixed by granting image membership access to
snapshot images when the owner of the server is not performing the
snapshot/backup/shelve operation on the server. For example, an admin
shelves a user's server and the user needs to unshelve the server so the
user needs access to the shelved snapshot image.
Note that only the image owner may delete the image, so in the case of
a shelved offloaded server, if the user unshelves or deletes the server,
that operation will work but there will be a warning in the logs because
the shelved snapshot image could not be deleted since the user does not
own the image. Similarly, if an admin creates a snapshot of a server in
another project, the admin owns the snapshot image and the non-admin
project, while having shared image member access to see the image, cannot
delete the snapshot.
The bug fix applies to both the ``nova-osapi_compute`` and ``nova-compute``
service so older compute services will need to be patched.
Refer to the image API reference for details on image sharing:
https://developer.openstack.org/api-ref/image/v2/index.html#sharing
.. _Bug 1675791: https://launchpad.net/bugs/1675791