From: Daniel Henrique Barboza <danielhb413@gmail.com>
To: qemu-devel@nongnu.org
Cc: kwolf@redhat.com, Srikanth Aithal <bssrikanth@in.ibm.com>,
Daniel Henrique Barboza <danielhb413@gmail.com>,
jsnow@redhat.com
Subject: [Qemu-devel] [PATCH v7 3/4] crypto.c: cleanup created file when block_crypto_co_create_opts_luks fails
Date: Tue, 3 Sep 2019 10:57:07 -0300 [thread overview]
Message-ID: <20190903135708.21624-4-danielhb413@gmail.com> (raw)
In-Reply-To: <20190903135708.21624-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 delete
'filename' in case of failure. A failure in this point means that
the volume is now truncated/corrupted, so even if 'filename' was an
existing volume before calling qemu-img, it is now unusable. Deleting
the file it is not much worse than leaving it in the filesystem in
this scenario, and we don't have to deal with checking the file
pre-existence in the code.
* 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 | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/block/crypto.c b/block/crypto.c
index 7eb698774e..29496d247e 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;
@@ -596,9 +597,30 @@ static int coroutine_fn block_crypto_co_create_opts_luks(const char *filename,
ret = 0;
fail:
+ /*
+ * If an error occurred, delete 'filename'. Even if the file existed
+ * beforehand, it has been truncated and corrupted in the process.
+ */
+ if (ret) {
+ Error *local_err;
+ int r_del = bdrv_delete_file(bs, &local_err);
+ /*
+ * ENOTSUP will happen if the block driver doesn't support
+ * 'bdrv_co_delete_file'. ENOENT will be fired by
+ * 'raw_co_delete_file' if the file doesn't exist. Both are
+ * predictable (we're not verifying if the driver supports
+ * file deletion or if the file was created), thus we
+ * shouldn't report this back to the user.
+ */
+ if ((r_del < 0) && (r_del != -ENOTSUP) && (r_del != -ENOENT)) {
+ error_reportf_err(local_err, "%s: ", bs->filename);
+ }
+ }
+
bdrv_unref(bs);
qapi_free_QCryptoBlockCreateOptions(create_opts);
qobject_unref(cryptoopts);
+
return ret;
}
--
2.21.0
next prev parent reply other threads:[~2019-09-03 13:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-03 13:57 [Qemu-devel] [PATCH v7 0/4] delete created files when block_crypto_co_create_opts_luks fails Daniel Henrique Barboza
2019-09-03 13:57 ` [Qemu-devel] [PATCH v7 1/4] block: introducing 'bdrv_co_delete_file' interface Daniel Henrique Barboza
2019-10-18 12:24 ` Kevin Wolf
2019-09-03 13:57 ` [Qemu-devel] [PATCH v7 2/4] block.c: adding bdrv_delete_file Daniel Henrique Barboza
2019-10-18 12:37 ` Kevin Wolf
2019-09-03 13:57 ` Daniel Henrique Barboza [this message]
2019-10-18 12:42 ` [PATCH v7 3/4] crypto.c: cleanup created file when block_crypto_co_create_opts_luks fails Kevin Wolf
2019-09-03 13:57 ` [Qemu-devel] [PATCH v7 4/4] qemu-iotests: adding LUKS cleanup for non-UTF8 secret error Daniel Henrique Barboza
2019-10-17 17:42 ` [PATCH v7 0/4] delete created files when block_crypto_co_create_opts_luks fails Daniel Henrique Barboza
2019-10-17 17:48 ` 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=20190903135708.21624-4-danielhb413@gmail.com \
--to=danielhb413@gmail.com \
--cc=bssrikanth@in.ibm.com \
--cc=jsnow@redhat.com \
--cc=kwolf@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.