From nobody Mon Feb 2 07:26:59 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Received-SPF: pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) client-ip=8.43.85.245; envelope-from=devel-bounces@lists.libvirt.org; helo=lists.libvirt.org; Authentication-Results: mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass(p=reject dis=none) header.from=lists.libvirt.org ARC-Seal: i=1; a=rsa-sha256; t=1768313901; cv=none; d=zohomail.com; s=zohoarc; b=Wv1yF0PmVSpdI3x8QWL+sVCzCn7QOwjVDtLhuxCAWvOcUwRgI4wG8tL/YFR+9TxxY9VDn0fw/QUV2sreM7hjzuQlujYEFrRzq4QHs9WHpkYvhhZWNL8ZyVuNHCp0ZFM1AU707aO55bvzL/rrcO4kFogI0BZuj6oNSX9AqlVYMlQ= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1768313901; h=Content-Type:Content-Transfer-Encoding:Date:Date:From:From:List-Subscribe:List-Post:List-Owner:List-Id:List-Archive:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Reply-To:Reply-To:Subject:Subject:To:To:Message-Id:Cc; bh=KeoEI6j9PAq3k72E4wLnFaiL+LYhwtA8rP+KxCNw+h8=; b=AMNTcb4k+tL9mVMJMlOQmRaY1+xkUif36uzAR9DBuFwyD43vUGtAO8yGBct/T5pSIw3/55Zsg/VG0p6vnHPh7eAskuyrT1aGx/mCP3bWKP2h6clIovlqes+/4gQ7LJBxJmmb9keFEuGx8qlnaPMy6tw2Dpa7lKqTtwxAuWd13Mg= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=fail; spf=pass (zohomail.com: domain of lists.libvirt.org designates 8.43.85.245 as permitted sender) smtp.mailfrom=devel-bounces@lists.libvirt.org; dmarc=pass header.from= (p=reject dis=none) Return-Path: Received: from lists.libvirt.org (lists.libvirt.org [8.43.85.245]) by mx.zohomail.com with SMTPS id 1768313901693187.18006412709576; Tue, 13 Jan 2026 06:18:21 -0800 (PST) Received: by lists.libvirt.org (Postfix, from userid 993) id A9FCF418B6; Tue, 13 Jan 2026 09:18:20 -0500 (EST) Received: from [172.19.199.83] (lists.libvirt.org [8.43.85.245]) by lists.libvirt.org (Postfix) with ESMTP id F0B934196F; Tue, 13 Jan 2026 09:17:43 -0500 (EST) Received: by lists.libvirt.org (Postfix, from userid 993) id 97D12418AD; Tue, 13 Jan 2026 09:17:36 -0500 (EST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (3072 bits) server-digest SHA256) (No client certificate requested) by lists.libvirt.org (Postfix) with ESMTPS id 1F80B4189B for ; Tue, 13 Jan 2026 09:17:35 -0500 (EST) Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-327-lXkmb42VMjGMMxqwBE95NA-1; Tue, 13 Jan 2026 09:17:33 -0500 Received: from mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id BE059180035C for ; Tue, 13 Jan 2026 14:17:32 +0000 (UTC) Received: from speedmetal.lan (unknown [10.45.242.3]) by mx-prod-int-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 0EF5A30001A2 for ; Tue, 13 Jan 2026 14:17:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on lists.libvirt.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_PASS autolearn=unavailable autolearn_force=no version=4.0.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1768313854; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=KeoEI6j9PAq3k72E4wLnFaiL+LYhwtA8rP+KxCNw+h8=; b=Ucx6b1E5n1/wX64Vy/UmrgTesCavRBE6Y1je1raweXl28Ix0h9vJHDqT4ecVR/Ehc9RU/v gddPzGjDXTMlkKY9zeyPA3WM/dJOKrvEZ57jQ/XObFhgWghJwlW0+20gWbkMglclfwNgEq q8aESSls1iX/JXp16dBlwl9D/Cch4Oc= X-MC-Unique: lXkmb42VMjGMMxqwBE95NA-1 X-Mimecast-MFC-AGG-ID: lXkmb42VMjGMMxqwBE95NA_1768313852 To: devel@lists.libvirt.org Subject: [PATCH] qemuSecurityMoveImageMetadata: Move seclabels only to virStorageSource of same type Date: Tue, 13 Jan 2026 15:17:30 +0100 Message-ID: <82a537dbf74114bdb2b00b4decd1c917a930d9b0.1768313850.git.pkrempa@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.4 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: XVaQRQwp0lGW4y27Aa3qmiTfU_huhJYDFOlI3dxCVBM_1768313852 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable Message-ID-Hash: UGJ34T6IE774DOCVKC72JXHXZFA4IISK X-Message-ID-Hash: UGJ34T6IE774DOCVKC72JXHXZFA4IISK X-MailFrom: pkrempa@redhat.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.lists.libvirt.org-0; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Development discussions about the libvirt library & tools Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: Peter Krempa via Devel Reply-To: Peter Krempa X-ZohoMail-DKIM: fail (Header signature does not verify) X-ZM-MESSAGEID: 1768313903654158500 Content-Type: text/plain; charset="utf-8" From: Peter Krempa The concept of moving a seclabel is used e.g. when a new image is introduced to the backing chain (or one of the existing ones becomes active during block commit). What it does is that it moves the metedata remembering the original seclabel to the new image. That idea works reasonably well if both the original and new image are of same type e.g. a file, where they have comparable seclabel. It breaks down though when you e.g. create a snapshot stored in a 'file' on top of a disk originally backed by a 'block' storage source, since the seclabels differ quite siginificantly. This patch restricts the seclabel move in qemuSecurityMoveImageMetadata to happen only if the storage sources are of same type to avoid the issue. This means that the seclabels will not be remebered and will be restored to the default but it's better than to transfer wrong labels. Resolves: https://issues.redhat.com/browse/RHEL-114412 Signed-off-by: Peter Krempa Reviewed-by: Michal Privoznik --- src/qemu/qemu_security.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/src/qemu/qemu_security.c b/src/qemu/qemu_security.c index 6bb0f9170d..84cb981a96 100644 --- a/src/qemu/qemu_security.c +++ b/src/qemu/qemu_security.c @@ -201,6 +201,16 @@ qemuSecurityMoveImageMetadata(virQEMUDriver *driver, if (qemuDomainNamespaceEnabled(vm, QEMU_DOMAIN_NS_MOUNT)) pid =3D vm->pid; + /* Moving seclabel metadata makes sense only when 'src' and 'dst' are = of + * the same type. Otherwise 'dst' could end up with a seclabel that do= esn't + * make sense for it (e.g. a seclabel originating from a block device = /dev + * node moved to a file), once the seclabels are restored for it */ + if (src && dst && src->type !=3D dst->type) { + VIR_DEBUG("dropping security label metadata instead of moving it f= rom '%s' to '%s' due to type mismatch", + NULLSTR(src->path), NULLSTR(dst->path)); + dst =3D NULL; + } + return virSecurityManagerMoveImageMetadata(driver->securityManager, cfg->sharedFilesystems, pid, src, dst); --=20 2.52.0