file volume deletion, via virFileRemove, has some logic that depends on uid/gid owner of the path. This info is cached in the volume XML. We need to be sure we are using up to date uid/gid before attempting to delete the volume, otherwise we can hit a case like this:
- test.img created with uid=root - VM starts up using test.img, owner changed to uid=qemu - test.img pool is refreshed, uid=qemu is cached in the volume XML - VM shuts down, volume owner changed to gid=root - vol-delete test.img thinks uid=qemu, virFileRemove does setuid(qemu), fails to delete test.img since it is actually uid=root https://bugzilla.redhat.com/show_bug.cgi?id=1289327 --- src/storage/storage_driver.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/storage/storage_driver.c b/src/storage/storage_driver.c index 1d96618..ded54c9 100644 --- a/src/storage/storage_driver.c +++ b/src/storage/storage_driver.c @@ -1801,6 +1801,16 @@ storageVolDelete(virStorageVolPtr obj, goto cleanup; } + /* Need to ensure we are using up to date uid/gid for deletion */ + if (backend->refreshVol && + backend->refreshVol(obj->conn, pool, vol) < 0) { + /* The file may have been removed behind libvirt's back. Don't + error here, let the deletion fail or succeed instead */ + VIR_INFO("Failed to refresh volume before deletion: %s", + virGetLastErrorMessage()); + virResetLastError(); + } + if (storageVolDeleteInternal(obj, backend, pool, vol, flags, true) < 0) goto cleanup; -- 2.5.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
