Re: [PATCH] Remove incorrect special handling of /usr/libexec

On Mon, 26 Aug 2024 18:20:35 +1000 David Gibson wrote:

On Mon, Aug 26, 2024 at 09:55:47AM +0200, Stefano Brivio wrote:

...

On Mon, 26 Aug 2024 16:39:01 +1000 David Gibson wrote:

...

The statement in the comment about /usr/libexec being only for running on other hosts simply isn't true, neither in practice nor according to the FHS spec[0].

I don't remember where I took that meaning of /usr/libexec from, I guess it's from some outdated packaging guidelines (Fedora? Kata Containers?). Sure, it makes sense to fix that.

...

Furthermore this logic didn't even handle it correctly, since it would only handle binaries _directly_ in /usr/libexec, not those in (explicitly FHS permitted) subdirectories under /usr/libexec.

So, this change breaks the two cases I needed to cover with this, which are /usr/libexec/kata-agent in general, and /usr/libexec/qemu-kvm on RHEL 9.

Huh.. why?

Because they're not in PATH on the guest, so we can't execute them. As an alternative, we can unconditionally add /usr/libexec to it using $FIXUP. I added the lines moving stuff to /usr/bin before I implemented the $FIXUP mechanism, and I needed to run kata-agent as init. But now that $FIXUP is available, that's probably less invasive.

...

What does it fix?

I don't have a concrete case, but it would break anything where we're including this support binary, but the "front end" binary looks for it explicitly in /usr/libexec. Which I'd kind of expect to be most support binary cases, since by design /usr/libexec won't generally be in the PATH.

I see. Well, given the limited time I can spend on maintaining mbuto, I'd really prefer to just fix concrete issues, but this looks obvious enough -- as long as we have another way to keep qemu-kvm usable in the guest. -- Stefano