From nobody Mon Feb 9 21:21:24 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) client-ip=170.10.133.124; envelope-from=libvir-list-bounces@redhat.com; helo=us-smtp-delivery-124.mimecast.com; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=libvir-list-bounces@redhat.com; dmarc=fail(p=none dis=none) header.from=huawei.com Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.zohomail.com with SMTPS id 1631543431211616.3931864039268; Mon, 13 Sep 2021 07:30:31 -0700 (PDT) Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-496-S1SbP2gYM--EIUYmHQSAIg-1; Mon, 13 Sep 2021 10:30:27 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 493D01006AA2; Mon, 13 Sep 2021 14:30:22 +0000 (UTC) Received: from colo-mx.corp.redhat.com (colo-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1409460C9F; Mon, 13 Sep 2021 14:30:22 +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 D61351805986; Mon, 13 Sep 2021 14:30:21 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id 18DEUJg3019515 for ; Mon, 13 Sep 2021 10:30:19 -0400 Received: by smtp.corp.redhat.com (Postfix) id 7FF312157F58; Mon, 13 Sep 2021 14:30:19 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast02.extmail.prod.ext.rdu2.redhat.com [10.11.55.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7897E200E4AF for ; Mon, 13 Sep 2021 14:30:16 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9A25E8011AF for ; Mon, 13 Sep 2021 14:30:16 +0000 (UTC) Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-545-Xavw2VHwMV-rM061wHHm2w-1; Mon, 13 Sep 2021 10:30:14 -0400 Received: from dggemv711-chm.china.huawei.com (unknown [172.30.72.57]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4H7TKj3qB4z8yV6 for ; Mon, 13 Sep 2021 22:25:45 +0800 (CST) Received: from dggema765-chm.china.huawei.com (10.1.198.207) by dggemv711-chm.china.huawei.com (10.1.198.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Mon, 13 Sep 2021 22:30:10 +0800 Received: from localhost.localdomain (10.175.101.6) by dggema765-chm.china.huawei.com (10.1.198.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Mon, 13 Sep 2021 22:30:10 +0800 X-MC-Unique: S1SbP2gYM--EIUYmHQSAIg-1 X-MC-Unique: Xavw2VHwMV-rM061wHHm2w-1 From: Peng Liang To: Subject: [PATCH v3 2/2] qemu: don't change ownership of cache directory Date: Mon, 13 Sep 2021 22:23:47 +0800 Message-ID: <20210913142347.3023720-3-liangpeng10@huawei.com> In-Reply-To: <20210913142347.3023720-1-liangpeng10@huawei.com> References: <20210913142347.3023720-1-liangpeng10@huawei.com> MIME-Version: 1.0 X-Originating-IP: [10.175.101.6] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggema765-chm.china.huawei.com (10.1.198.207) X-CFilter-Loop: Reflected X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-MIME-Autoconverted: from quoted-printable to 8bit by lists01.pubmisc.prod.ext.phx2.redhat.com id 18DEUJg3019515 X-loop: libvir-list@redhat.com Cc: yubihong@huawei.com, liangpeng10@huawei.com, xiexiangyou@huawei.com 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: , Sender: libvir-list-bounces@redhat.com Errors-To: libvir-list-bounces@redhat.com X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=libvir-list-bounces@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1631543432164100005 Content-Type: text/plain; charset="utf-8" Commit 6bcf25017bc6 ("virDomainMemoryPeek API") introduced memory peek and commit 9936aecfd1b4 ("qemu: Implement the driver methods") introduced screenshot. Both of them will put temporary files in /var/cache/libvirt/qemu, and the temporary files are created by QEMU. Therefore, the ownership of /var/cache/libvirt/qemu should be changed to user and group configured in qemu.conf to make sure that QEMU process can create and write files in the cache directory. Libvirt will only put the temporary files in /var/cache/libvirt/qemu until commit cbde35899b90 ("Cache result of QEMU capabilities extraction"), which will put the cache of QEMU capabilities in 'capabilities' subdir of the cache directory. Because the capabilities is used by libvirt, the ownership of both 'capabilities' subdir and capabilitie files are root. However, when QEMU process runs as a regular user (e.g. qemu user), the ownership of /var/cache/libvirt/qemu will be changed to qemu:qemu while that of /var/cache/libvirt/qemu/capabilities will be still root:root. Then the regular user could spoof different capabilities, which maybe lead to denial of service. Since the previous patch has move the temp files of screenshot and memory peek to per-domain directory, no one except domain capabilities uses cacheDir currently. And since domain capabilities are used by libvirtd instead of QEMU, no need to change the ownership of cacheDir to qemu:qemu explicitly. Signed-off-by: Peng Liang --- src/qemu/qemu_driver.c | 7 ------- 1 file changed, 7 deletions(-) diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c index 7ffe5f1e3856..818889219b11 100644 --- a/src/qemu/qemu_driver.c +++ b/src/qemu/qemu_driver.c @@ -748,13 +748,6 @@ qemuStateInitialize(bool privileged, (int)cfg->group); goto error; } - if (chown(cfg->cacheDir, cfg->user, cfg->group) < 0) { - virReportSystemError(errno, - _("unable to set ownership of '%s' to %d:= %d"), - cfg->cacheDir, (int)cfg->user, - (int)cfg->group); - goto error; - } if (chown(cfg->saveDir, cfg->user, cfg->group) < 0) { virReportSystemError(errno, _("unable to set ownership of '%s' to %d:= %d"), --=20 2.31.1