From patchwork Wed Aug 7 14:21:13 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Henrique Barboza X-Patchwork-Id: 11082273 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0AB711399 for ; Wed, 7 Aug 2019 14:23:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id EFB272881B for ; Wed, 7 Aug 2019 14:23:04 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id E41F8285B6; Wed, 7 Aug 2019 14:23:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.0 required=2.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 563B128995 for ; Wed, 7 Aug 2019 14:23:04 +0000 (UTC) Received: from localhost ([::1]:41788 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvMqF-0001E1-LE for patchwork-qemu-devel@patchwork.kernel.org; Wed, 07 Aug 2019 10:23:03 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:39042) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hvMoq-00067D-FY for qemu-devel@nongnu.org; Wed, 07 Aug 2019 10:21:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hvMop-000076-AA for qemu-devel@nongnu.org; Wed, 07 Aug 2019 10:21:36 -0400 Received: from mail-qt1-x842.google.com ([2607:f8b0:4864:20::842]:34685) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hvMop-00006x-5q for qemu-devel@nongnu.org; Wed, 07 Aug 2019 10:21:35 -0400 Received: by mail-qt1-x842.google.com with SMTP id k10so19333533qtq.1 for ; Wed, 07 Aug 2019 07:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=dGfD+OKaAJtklYlmiZJfVWpoqCv42S59cVjzwBeRJNs=; b=fLaUpvx+YTXTwSrSe/iAG0Z7uSXo7Wcgu4E24TBm/UxIfq8POpcJqdfiuTRvX9qj0T D6klQjWfclW1ugpsxa90cjxRH0UPoXToibXlZ97+bCAQx7cmIGjNmyqFFPvS8lnPtbjy b4+DGYcMBePyMOjTjskvRJHvyVldEICdbuAFToUgeejyhsnHf7V94VFD+V1ry73cODxz TAyoze6y3dn2h2aaCTjoYox6oOlUSP42XTbF09Nk+k8cxhUn+6/m69zosYdYgQaGVUsL dQsR3wilDq4pkcqENBDtFBw50dmExmY/ylQ9auzzSIRuU0DUgC0unwCOw1LCRelYWxPb JEAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=dGfD+OKaAJtklYlmiZJfVWpoqCv42S59cVjzwBeRJNs=; b=Or33CUo2rDvdoQRiylAv7dCICyKOTQ6BgTri14+9sLQaABzLu8NxIW7RPr5ajdDK+E m2NksVpkwQq3rT7hOTgrC60zmeB09c3PVlwzlFOxhqzkA6NOwO9CoUVkSaX9B21v4PIQ ObyGeh4N8DscsaNTP3IWsZ0NiHIQkaoe1WVjnHoYGoUUWerzdFl9gHoM0QzBd82i8uBm 0HGeG6rP+Y1tCMR+UnxvqvLRBRiS4fZzUMY1myJ0KNqfWrk5ghQiPXU/tHiYAwf4VWJ0 MOk3uYn7MRd7UqwQWQEckX5hjS+Lbgclc3rDm5RtbrbkPOBuWS/Qy/OZwoBzj2Ek/tzb oWPw== X-Gm-Message-State: APjAAAVOWPuK6otuE2EJ4+RJYwdoRKmgoXE9Q+Xh2XFGd8bH8opdbGME 7cIKLPkAp7YSijw0tYmBsFPpULFi X-Google-Smtp-Source: APXvYqwDxuCSHvRbxW42whOvF1eLZbuBwmtBfH2LmZ7I+ICRCKOilf7wV2xsxC1VIRmeqhibqa10IA== X-Received: by 2002:ac8:c0e:: with SMTP id k14mr8248597qti.72.1565187694567; Wed, 07 Aug 2019 07:21:34 -0700 (PDT) Received: from rekt.ibmuc.com ([2804:431:c7c7:5ef4:7266:b7a7:9def:f8fc]) by smtp.gmail.com with ESMTPSA id e18sm31472034qkm.49.2019.08.07.07.21.32 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 07 Aug 2019 07:21:34 -0700 (PDT) From: Daniel Henrique Barboza To: qemu-devel@nongnu.org Date: Wed, 7 Aug 2019 11:21:13 -0300 Message-Id: <20190807142114.17569-4-danielhb413@gmail.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190807142114.17569-1-danielhb413@gmail.com> References: <20190807142114.17569-1-danielhb413@gmail.com> MIME-Version: 1.0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::842 Subject: [Qemu-devel] [PATCH v5 3/4] crypto.c: cleanup created file when block_crypto_co_create_opts_luks fails X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kwolf@redhat.com, berrange@redhat.com, Daniel Henrique Barboza , mreitz@redhat.com, Srikanth Aithal , jsnow@redhat.com Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 Suggested-by: Kevin Wolf Signed-off-by: Daniel Henrique Barboza --- block/crypto.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/block/crypto.c b/block/crypto.c index 8237424ae6..8ffca81df6 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; @@ -575,6 +576,25 @@ fail: bdrv_unref(bs); qapi_free_QCryptoBlockCreateOptions(create_opts); qobject_unref(cryptoopts); + + /* + * If an error occurred, delete the file. 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(filename, &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: ", bs->filename); + } + } + return ret; }