[libvirt] [PATCH 1/3] storage: refresh volume before deletion

Cole Robinson crobinso at redhat.com
Wed Mar 9 17:38:58 UTC 2016


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




More information about the libvir-list mailing list