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 <[email protected]>
> ---
> 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.
