From nobody Mon Apr 29 20:59:17 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) client-ip=209.132.183.28; envelope-from=libvir-list-bounces@redhat.com; helo=mx1.redhat.com; Authentication-Results: mx.zohomail.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass(p=none dis=none) header.from=redhat.com ARC-Seal: i=1; a=rsa-sha256; t=1568630124; cv=none; d=zoho.com; s=zohoarc; b=nJVEuyyZMCZWbNeBoEaS5U6V6/P4A7rekucIjIpjA0LQG7fH2omfLL20CU7X7G5VH/U8m7A+Mnk5UXo+K7IPjI/uADJBZZHNfbaUM12iQbQUB6Yj5LSymqJM9efNXSYUPEvYPdNcB+hamJyGQcVjH8TjlBt5eKx4Un/fdQuvnGo= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zoho.com; s=zohoarc; t=1568630124; h=Content-Type:Content-Transfer-Encoding:Date:From:List-Subscribe:List-Post:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:To:ARC-Authentication-Results; bh=YRYoSTlkUR1mvjdNtGchGQs541a23xc/N39DMW7aiD8=; b=fnnpTezm63x0RkQoAvUAvoQXxfOXdqJe8rJ6ULAjReePaF9HY9xIhHRqvTGxm5Rq4TzkbpIMIE0UKKTmBsVLecFqQkmxrfoDBwMnHf/mTLexbwmKVw8VyEFt2++ENjTIIlVzWjW43UwXN1aOIZtG4mv5/qnNRccmmdxHD9TSm6A= ARC-Authentication-Results: i=1; mx.zoho.com; spf=pass (zoho.com: domain of redhat.com designates 209.132.183.28 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=pass header.from= (p=none dis=none) header.from= Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by mx.zohomail.com with SMTPS id 1568630124789441.66494284864257; Mon, 16 Sep 2019 03:35:24 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 78D423082B6D; Mon, 16 Sep 2019 10:35:21 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DA8276012C; Mon, 16 Sep 2019 10:35:20 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by colo-mx.corp.redhat.com (Postfix) with ESMTP id F23DC4EE6D; Mon, 16 Sep 2019 10:35:19 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id x8GAYbVo018898 for ; Mon, 16 Sep 2019 06:34:37 -0400 Received: by smtp.corp.redhat.com (Postfix) id 7F5FD5C21A; Mon, 16 Sep 2019 10:34:37 +0000 (UTC) Received: from moe.brq.redhat.com (unknown [10.43.2.30]) by smtp.corp.redhat.com (Postfix) with ESMTP id 091F95C1D6 for ; Mon, 16 Sep 2019 10:34:34 +0000 (UTC) From: Michal Privoznik To: libvir-list@redhat.com Date: Mon, 16 Sep 2019 12:34:32 +0200 Message-Id: <6fd1644cde1701c9c7072ab7c7f91ee159ad45a3.1568630009.git.mprivozn@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-loop: libvir-list@redhat.com Subject: [libvirt] [PATCH] qemu_blockjob: Remove secdriver metadata for whole backing chain on job completion X-BeenThere: libvir-list@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: Development discussions about the libvirt library & tools List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.45]); Mon, 16 Sep 2019 10:35:23 +0000 (UTC) Content-Type: text/plain; charset="utf-8" Turns out, block mirror is not the only job a disk can have. It can also do commits of one layer into the other. Or possibly some other tricks too. Problem is that while we set seclabels on given layers of backing chain when the job is starting (via qemuDomainStorageSourceAccessAllow()) we don't restore them when job finishes. This leaves XATTRs set and corresponding images unusable. Signed-off-by: Michal Privoznik --- Not sure if we want to remove XATTRs for the top layer too or just the rest of the backing chain (n=3Ddisk->src vs. n=3Ddisk->src->backingStore). Peter? src/qemu/qemu_blockjob.c | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/src/qemu/qemu_blockjob.c b/src/qemu/qemu_blockjob.c index a991309ee7..6408f95e4e 100644 --- a/src/qemu/qemu_blockjob.c +++ b/src/qemu/qemu_blockjob.c @@ -658,9 +658,9 @@ qemuBlockJobEventProcessLegacyCompleted(virQEMUDriverPt= r driver, virObjectUnref(disk->src); disk->src =3D disk->mirror; } else { + virStorageSourcePtr n; + if (disk->mirror) { - virStorageSourcePtr n; - virDomainLockImageDetach(driver->lockManager, vm, disk->mirror= ); =20 /* Ideally, we would restore seclabels on the backing chain he= re @@ -678,6 +678,16 @@ qemuBlockJobEventProcessLegacyCompleted(virQEMUDriverP= tr driver, =20 virObjectUnref(disk->mirror); } + + for (n =3D disk->src; virStorageSourceIsBacking(n); n =3D n->backi= ngStore) { + if (qemuSecurityMoveImageMetadata(driver, vm, n, NULL) < 0) { + VIR_WARN("Unable to remove disk metadata on " + "vm %s from %s (disk target %s)", + vm->def->name, + NULLSTR(n->path), + disk->dst); + } + } } =20 /* Recompute the cached backing chain to match our --=20 2.21.0 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list