On Thu, Jan 15, 2026 at 08:38:36 +0100, Michal Prívozník via Devel wrote: > On 1/14/26 20:39, Erik Huelsmann wrote: > > Hi Michal,
[...] > >> Another alternative is to move profile generation into its separate > >> step. So then we'd have: > >> > >> qemuProcessPrepareDomain(): > >> 1) gen seclabel /* here only SELinux/DAC drivers would do something > >> useful. For AppArmor it'd be a NOP. */ > >> 2) generate all the paths > >> 3) write profile /* only AppArmor would act upon, for SELinux and > >> AppArmor it'd be nop. */ > >> > >> Let me see if that'd would fix the issue. > > > > From the fact that you submitted the patches, I think I understand the > > change above didn't work. > > It did, but I'm not sure about all the implications of it. I mean, if > there's something, hidden under a dozen of function calls from > qemuProcessPrepareDomain() that expects seclabel to be generated, then > moving the generation at the end is no good. I'm not exactly sure how the apparmour profile is used in this case, because in qemuProcessPrepareDomain() the qemu process certainly is not around. What *can* be around are some various helper processes that are launched (e.g. 'numad' is invoked, some vhost-user backend binaries are invoked (at least for capability detection but I remember one case where some "useful" setup was done there too, at least historically)). So at the very least, with this move libvirt must be able to do the things above and hopefully I didn't overlook anything. That's the reason why I didn't put an R-b on those patches yet, because at least code-wise they look good to me. > > > Is there anything I can do to help this > > patch set? > > You can test the patch set and if it works you can reply to the cover > letter with your Tested-by tag. > > Michal >
