[libvirt] [PATCH 08/12] storage: Cleanup failures virStorageBackendCreateExecCommand

Peter Krempa pkrempa at redhat.com
Tue Oct 13 12:50:01 UTC 2015


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 at redhat.com>
> ---
>  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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151013/81b6f114/attachment-0001.sig>


More information about the libvir-list mailing list