Re: [PATCH] test: Update README.md

On Wed, 24 Sep 2025 12:20:03 +0100 Daniel P. Berrangé wrote:

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.

I'd rather call it observation. We're just piling up workarounds because merge requests are not really evaluated or accepted, for example https://github.com/fedora-selinux/selinux-policy/pull/1613. Your own comment to it: https://github.com/fedora-selinux/selinux-policy/pull/1613#issuecomment-1467... perfectly explains one of the biggest maintainability concerns I have, because not being able to use interfaces as designed leads to issues such as: https://github.com/fedora-selinux/selinux-policy/issues/2579 for which, again, I could propose a simple change, but I don't exactly have confidence that it will be considered. That leads in turn to more workarounds, say: https://passt.top/passt/commit/?id=87471731e6bb0b5df3a50277527caf3381b45ee4 https://passt.top/passt/commit/?id=98d474c8950e9cc5715d5686614fb0f504377303 I don't understand how the fact that it's been like that since 2007 would suggest a positive or negative correlation to maintainability. Things keeps breaking and I keep adding more workarounds, not fixes. You can go ahead and blame me for that, but I was talking about how *I* perceive maintainability. Again:

1. libvirt's SELinux policy doesn't seem to be really maintainable / long-term sustainable to me ^^

...we probably have different concepts of it. That doesn't make it 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.

It depends on the use case. For the use case at hand, we would be absolutely fine with things breaking every six months, or even more frequently.

...

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.

About disk images, of course, that's what I added for libguestfs: /** mrwlk and that's the same in libvirt's AppArmor policy. The set of permitted capabilities is very different, though, and libguestfs doesn't of course need all those helpers or, say, the ability to mount /dev, which, with AppArmor, can't be qualified / limited much further than that.

Only the spawned QEMU could be confined strictly, and that would be equiv to what is already done with libvirt's policy for QEMU.

...see links above? Those are not equivalent. -- Stefano