On Tue, Nov 12, 2024 at 02:22:19PM +0100, Stefano Brivio wrote: > On Tue, 12 Nov 2024 13:08:00 +0000 > "Richard W.M. Jones" <rjo...@redhat.com> wrote: > > > Do you know where the apparmor profile is shipped right now? Could it > > be in libvirt (src/security/apparmor)? > > Yes, but that's the one for libvirt components themselves, and used on > Debian without changes from upstream. I don't think that that AppArmor > profile should cover libguestfs as well, correct?
I'm not sure. Probably the answer is whatever the thing is that now allows libguestfs to launch qemu directly, should also allow libguestfs to launch passt directly. > Note that, as far as I know, this issue only happens with libguestfs > using "direct" mode (even though it's not explicitly set anywhere, so > I'm not sure I got this right). Direct mode (run qemu directly) is the upstream default, and also used by Debian. But it's not what we use in Fedora. In Fedora we use the libvirt mode (run qemu via libvirt). This affects passt because in libvirt mode (on Fedora) the session libvirtd will run passt. So you should expect that Debian & Fedora behave differently, as well as the AppArmour vs SELinux difference. > > We don't ship any SELinux or apparmor profiles upstream in libguestfs > > or the tools, so assigning the bug upstream to us won't result in any > > useful outcome. > > Right... I noticed as I wanted to submit an upstream patch for > libguestfs to fix this and I realised that there are no AppArmor > profiles there. > > By "reassigning to guestfs-tools or libguestfs" I actually meant the > downstream packages. .. in Debian. A similar bug was assigned to selinux-policy in RHEL: https://issues.redhat.com/browse/RHEL-65502 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html
