[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

 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;

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]