Re: [PATCH] test: Update README.md

On Wed, Sep 24, 2025 at 01:05:53PM +0200, Stefano Brivio wrote:

On Wed, 24 Sep 2025 11:31:31 +0100 "Richard W.M. Jones" wrote:

...

On Wed, Sep 24, 2025 at 11:09:09AM +0200, Stefano Brivio wrote:

...

And now that you say that, I just realised that it would be as simple as:

https://libguestfs.org/guestfs-faq.1.html#permission-denied-when-running-lib...

LIBGUESTFS_BACKEND=direct virt-edit...

While that will indeed work, we're trying to discourage people from doing that, since it removes the other good things that libvirt does, such as setting up SELinux.

Oh, I see. I guess it makes sense, with a number of caveats:

1. libvirt's SELinux policy doesn't seem to be really maintainable / long-term sustainable to me, especially because it's still part of fedora-selinux

Well it isn't ideal that Fedora policy is largely centralized, but it has been maintained it since 2007, so claiming it is not long term sustainable is just FUD.

2. it adds a rather artificial dependency on libvirt, so in the end you're running more things, and more complicated ones, even if it's not needed

Libvirt provides a stable interface to interacting with QEMU over decades. QEMU's own interface is only guaranteed stable over 2 releases. As QEMU changes its interface and/or best practice configuration approach, libvirt adapts to this so every app doesn't have to repeat this work.

3. the profile is still much looser than what a libguestfs specific profile could be, see for example the AppArmor policy I introduced at:

https://salsa.debian.org/libvirt-team/guestfs-tools/-/commit/e638b1bcb8a6621...

which, despite being rather loose, is still arguably much stricter than this beast (and related add-ons):

https://gitlab.com/libvirt/libvirt/-/blob/master/src/security/apparmor/usr.s...

and I think a strict subset of it, as well.

This is the policy for the libvirt daemon, which is separate from the policy that the QEMU guest runs under - the latter is constrained to limit access to resources configured for the guest VM. The libvirt daemon policy needs to be loose by default, since users want libvirt to be able to access a wide range of files and resources. This same need applies to guestfish - it needs to access arbitrarily specified disk images, so would need a very loose policy. Only the spawned QEMU could be confined strictly, and that would be equiv to what is already done with libvirt's policy for QEMU. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|