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.