On Thu, Jan 15, 2026 at 3:07 AM Peter Krempa <[email protected]> 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 <[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.
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/[email protected]/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
