On Tue, Feb 04, 2025 at 08:14:48PM +0100, Stefano Brivio wrote:On Tue, 4 Feb 2025 18:46:37 +0000 Andrea Bolognani <abologna(a)redhat.com> wrote:That could work, I suppose. Needs to be discussed upstream, making sure to involve those who are more experienced with AppArmor than I am, especially since it's not just a matter of updating the policy but fundamentally changing how the driver works when operating in unprivileged mode.Right. That's what we did for libguestfs as well, the image can be *almost* anywhere. But it's not free-for-all: you're just granting *limited* filesystem access (not to sysfs, not to /etc, and so on). And I had to build a *very* loose profile for libguestfs because that applies to root as well, but for rootless libvirtd, it might even make sense to restrict access to just @{HOME}/** and /tmp/** (that's what I did for stand-alone passt, for example).2. (most reasonable I think) don't use per-VM profiles for the rootless case. Define a single "libvirt-user" (or "libvirt-session") profile and use that. We could copy it from the existing ones I suppose.Sounds to me like this would require granting the QEMU process access to roughly the entire filesystem? The disk image could live anywhere after all, and if we can't dynamically add a rule for the exact path the only way out is a free-for-all approach.I'll try to submit a pull request at least for Debian in a couple of days.Be aware that I will emphatically refuse to introduce changes to the Debian package unless they have been merged upstream first. AppArmor support lives in the upstream repository, and all fixes and improvements have to go through it. -- Andrea Bolognani / Red Hat / Virtualization