On Thu, Jan 15, 2026 at 3:07 AM Peter Krempa <pkrempa@redhat.com> wrote:
On Mon, Jan 05, 2026 at 14:27:23 -0600, Wesley Hershberger via Devel wrote:
Adds a read-only attribute allowWrite to a disk's backingStore source element for the duration of a block commit operation, which records that write access is needed for that backingStore.
This is used by the AppArmor security driver when re-generating profiles.
Partial-Resolves: #692 Bug-Ubuntu: https://bugs.launchpad.net/bugs/2126574 Signed-off-by: Wesley Hershberger <wesley.hershberger@canonical.com> --- src/conf/domain_conf.c | 7 +++++++ src/conf/storage_source_conf.c | 2 ++ src/conf/storage_source_conf.h | 3 +++ src/qemu/qemu_block.c | 26 ++++++++++++++++++++++++++ src/qemu/qemu_blockjob.c | 8 ++++++++ src/qemu/qemu_security.c | 7 +++++++ src/security/virt-aa-helper.c | 7 ++----- 7 files changed, 55 insertions(+), 5 deletions(-)
[...]
diff --git a/src/conf/storage_source_conf.h b/src/conf/storage_source_conf.h index fc868b31af..0a54ff8c9c 100644 --- a/src/conf/storage_source_conf.h +++ b/src/conf/storage_source_conf.h @@ -449,6 +449,9 @@ struct _virStorageSource { * to do this decision. */ bool seclabelSkipRemember; + /* Temporary write access to this source is required (currently only for + * QEMU blockcommit) */ + bool secAllowWrite;
We internally track the writable state in the block job data (by knowing which images are undergoing a block commit operation). This would just duplicate the data and requiring us to keep it in sync just to be able to smuggle it into the helper process.
I currently don't remember if you are getting the whole status XML, with also the qemu driver private data, where you could do the same inference, or just the normal XML with some status bits which are inside the domain XML.
Either way I don't like adding another flag which is not the primary source of information.
If the full status XML is fed to the helper process you'll need to look in the 'blockjobs' section (see tests/qemustatusxml2xmldata/blockjob-blockdev-in.xml as example) and lookup the images based on job type and nodename.
If the whole status XML is not fed to the helper thne I'd suggest to pass another block of private data to the helper process rather than sprinkling them into the runtime definitions and requiring to keep them in sync, so that it's tightly coupled what's required by the helper function and where we provide it from.
Thanks for the pointer on domstatus->blockjobs. As Michal noted, the domstatus XML with the blockjob data isn't fed into the virt-aa-helper today. That's the solution I'd prefer here, but... - The qemu driver privateData is a field of virDomainObj - The secdriver is only passed a virDomainDef I'm not sure if/how it's possible to go from virDomainDef to virDomainObj. There are the virDomainObjListFindBy* functions, but they require a reference to the domain driver which I don't think we have in the secdriver either. Here's a little additional context on these patches; I should have linked this in the cover letter: https://www.mail-archive.com/devel@lists.libvirt.org/msg13340.html That's why I went with changes to the XML rather than trying to plumb the info through separately. Thanks for your help, I really appreciate it. ~Wesley