All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, berrange@redhat.com,
	Daniel Henrique Barboza <danielhb413@gmail.com>,
	mreitz@redhat.com, Srikanth Aithal <bssrikanth@in.ibm.com>,
	jsnow@redhat.com
Subject: [Qemu-devel] [PATCH v4 3/4] crypto.c: cleanup created file when block_crypto_co_create_opts_luks fails
Date: Fri, 28 Jun 2019 16:45:11 -0300	[thread overview]
Message-ID: <20190628194512.21311-4-danielhb413@gmail.com> (raw)
In-Reply-To: <20190628194512.21311-1-danielhb413@gmail.com>

When using a non-UTF8 secret to create a volume using qemu-img, the
following error happens:

$ qemu-img create -f luks --object secret,id=vol_1_encrypt0,file=vol_resize_pool.vol_1.secret.qzVQrI -o key-secret=vol_1_encrypt0 /var/tmp/pool_target/vol_1 10240K

Formatting '/var/tmp/pool_target/vol_1', fmt=luks size=10485760 key-secret=vol_1_encrypt0
qemu-img: /var/tmp/pool_target/vol_1: Data from secret vol_1_encrypt0 is not valid UTF-8

However, the created file /var/tmp/pool_target/vol_1 is left behind in the
file system after the failure. This behavior can be observed when creating
the volume using Libvirt, via 'virsh vol-create', and then getting "volume
target path already exist" errors when trying to re-create the volume.

The volume file is created inside block_crypto_co_create_opts_luks, in
block/crypto.c. If the bdrv_create_file() call is successful but any
succeeding step fails*, the existing 'fail' label does not take into
account the created file, leaving it behind.

This patch changes block_crypto_co_create_opts_luks to check if @filename
is an existing file before bdrv_create_file is called. In case of failure,
if @filename didn't exist before, check again for its existence and,
if affirmative, erase it by calling bdrv_delete_file.

* in our case, block_crypto_co_create_generic calls qcrypto_block_create,
which calls qcrypto_block_luks_create, and this function fails when
calling qcrypto_secret_lookup_as_utf8.

Reported-by: Srikanth Aithal <bssrikanth@in.ibm.com>
Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
---
 block/crypto.c | 31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/block/crypto.c b/block/crypto.c
index 8237424ae6..146f3eb721 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -30,6 +30,7 @@
 #include "qapi/error.h"
 #include "qemu/module.h"
 #include "qemu/option.h"
+#include "qemu/cutils.h"
 #include "crypto.h"
 
 typedef struct BlockCrypto BlockCrypto;
@@ -535,6 +536,8 @@ static int coroutine_fn block_crypto_co_create_opts_luks(const char *filename,
     BlockDriverState *bs = NULL;
     QDict *cryptoopts;
     int64_t size;
+    const char *path;
+    bool file_already_existed = false;
     int ret;
 
     /* Parse options */
@@ -551,6 +554,15 @@ static int coroutine_fn block_crypto_co_create_opts_luks(const char *filename,
         goto fail;
     }
 
+    /*
+     * Check if 'filename' represents a local file that already
+     * exists in the file system prior to bdrv_create_file. Strip
+     * the leading 'file:' from the filename if it exists.
+     */
+    path = filename;
+    strstart(path, "file:", &path);
+    file_already_existed = bdrv_path_is_regular_file(path);
+
     /* Create protocol layer */
     ret = bdrv_create_file(filename, opts, errp);
     if (ret < 0) {
@@ -575,6 +587,25 @@ fail:
     bdrv_unref(bs);
     qapi_free_QCryptoBlockCreateOptions(create_opts);
     qobject_unref(cryptoopts);
+
+    /*
+     * If an error occurred and we ended up creating a bogus
+     * 'filename' file, delete it
+     */
+    if (ret && !file_already_existed && bdrv_path_is_regular_file(path)) {
+        Error *local_err;
+        int r_del = bdrv_delete_file(path, &local_err);
+        /*
+         * ENOTSUP will happen if the block driver doesn't support
+         * 'bdrv_co_delete_file'. ENOENT will happen if the file
+         * doesn't exist. Both are predictable and shouldn't be
+         * reported back to the user.
+         */
+        if ((r_del < 0) && (r_del != -ENOTSUP) && (r_del != -ENOENT)) {
+            error_reportf_err(local_err, "%s: ", path);
+        }
+    }
+
     return ret;
 }
 
-- 
2.20.1



  parent reply	other threads:[~2019-06-28 19:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28 19:45 [Qemu-devel] [PATCH v4 0/4] delete created files when block_crypto_co_create_opts_luks fails Daniel Henrique Barboza
2019-06-28 19:45 ` [Qemu-devel] [PATCH v4 1/4] block: introducing 'bdrv_co_delete_file' interface Daniel Henrique Barboza
2019-08-02 16:07   ` Kevin Wolf
2019-08-06 13:27     ` Daniel Henrique Barboza
2019-08-06 15:21       ` Kevin Wolf
2019-08-06 17:02         ` Daniel Henrique Barboza
2019-06-28 19:45 ` [Qemu-devel] [PATCH v4 2/4] block.c: adding bdrv_delete_file Daniel Henrique Barboza
2019-06-28 19:45 ` Daniel Henrique Barboza [this message]
2019-06-28 19:45 ` [Qemu-devel] [PATCH v4 4/4] qemu-iotests: adding LUKS cleanup for non-UTF8 secret error Daniel Henrique Barboza
2019-07-31 11:00 ` [Qemu-devel] [PATCH v4 0/4] delete created files when block_crypto_co_create_opts_luks fails Daniel Henrique Barboza

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190628194512.21311-4-danielhb413@gmail.com \
    --to=danielhb413@gmail.com \
    --cc=berrange@redhat.com \
    --cc=bssrikanth@in.ibm.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.