On Mon, Jan 19, 2026 at 11:38:43 -0600, Wesley Hershberger wrote: > On Thu, Jan 15, 2026 at 3:07 AM Peter Krempa <[email protected]> wrote:
[...] > > 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. Hmm, yeah that's a pitty. I think the only viable solution would be via a callback function and a private data pointer. I wonder how we can address the disconnect between how apparmor works and how selinux/dac work. Specifically the part where qemu driver code needs to be able to reconstruct the state which the other drivers keep in seclabels. Obviously for the disk images you could create an specific XATTR labels noting the current state akin to the selinux label. > 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. I understand that this feels simpler but this specific field serves no purpose other than duplicate state we store elsewhere which comes with extra cost to keep in sync and that should be avoided. The parser and formatter are complex-enough as they stand currently.
