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