On Fri, Oct 09, 2015 at 09:34:07 -0400, John Ferlan wrote: > After a successful qemu-img/qcow-create of the backing file, if we > fail to stat the file, change it owner/group, or mode, then the > cleanup path should delete the file. > > Also moved the virCommandSetUID/virCommandSetGID inside the condition > used to actually run the command rather than randomly setting and not > using it if the file had been created. The 'cmd' buffer is only used > if we need to create. > > Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> > --- > src/storage/storage_backend.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > > diff --git a/src/storage/storage_backend.c b/src/storage/storage_backend.c > index a375fe0..7d0de63 100644 > --- a/src/storage/storage_backend.c > +++ b/src/storage/storage_backend.c ... > @@ -737,6 +740,8 @@ virStorageBackendCreateExecCommand(virStoragePoolObjPtr pool, > ret = 0; > > cleanup: > + if (ret < 0 && filecreated) > + unlink(vol->target.path); This might not work if the volume was created with different uid/gid as the process that is attempting to delete it (in case of e.g. NFS.). Peter
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list