* [PATCH] Remove incorrect special handling of /usr/libexec @ 2024-08-26 6:39 David Gibson 2024-08-26 7:55 ` Stefano Brivio 0 siblings, 1 reply; 7+ messages in thread From: David Gibson @ 2024-08-26 6:39 UTC (permalink / raw) To: Stefano Brivio; +Cc: passt-dev, David Gibson 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]. 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. [0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html Signed-off-by: David Gibson <david@gibson.dropbear.id.au> --- mbuto | 8 -------- 1 file changed, 8 deletions(-) diff --git a/mbuto b/mbuto index a2a8147..5e8ea9c 100755 --- a/mbuto +++ b/mbuto @@ -752,14 +752,6 @@ prog_add() { unset IFS [ -z "${__bin}" ] && err "Can't source ${1}" - # Binaries in /usr/libexec are meant to run on other hosts only, so they - # can't reside in /usr/libexec on the target image. Move to /usr/bin. - if [ "$("${DIRNAME}" "${__bin}")" = "/usr/libexec" ]; then - __bindir="${wd}/usr/bin" - else - __bindir="${wd}$("${DIRNAME}" "${__bin}")" - fi - "${MKDIR}" -p "${__bindir}" "${CP}" --preserve=all "${__bin}" "${__bindir}" -- @@ -752,14 +752,6 @@ prog_add() { unset IFS [ -z "${__bin}" ] && err "Can't source ${1}" - # Binaries in /usr/libexec are meant to run on other hosts only, so they - # can't reside in /usr/libexec on the target image. Move to /usr/bin. - if [ "$("${DIRNAME}" "${__bin}")" = "/usr/libexec" ]; then - __bindir="${wd}/usr/bin" - else - __bindir="${wd}$("${DIRNAME}" "${__bin}")" - fi - "${MKDIR}" -p "${__bindir}" "${CP}" --preserve=all "${__bin}" "${__bindir}" -- 2.46.0 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] Remove incorrect special handling of /usr/libexec 2024-08-26 6:39 [PATCH] Remove incorrect special handling of /usr/libexec David Gibson @ 2024-08-26 7:55 ` Stefano Brivio 2024-08-26 8:20 ` David Gibson 0 siblings, 1 reply; 7+ messages in thread From: Stefano Brivio @ 2024-08-26 7:55 UTC (permalink / raw) To: David Gibson; +Cc: passt-dev On Mon, 26 Aug 2024 16:39:01 +1000 David Gibson <david@gibson.dropbear.id.au> 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. What does it fix? > [0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au> > --- > mbuto | 8 -------- > 1 file changed, 8 deletions(-) > > diff --git a/mbuto b/mbuto > index a2a8147..5e8ea9c 100755 > --- a/mbuto > +++ b/mbuto > @@ -752,14 +752,6 @@ prog_add() { > unset IFS > [ -z "${__bin}" ] && err "Can't source ${1}" > > - # Binaries in /usr/libexec are meant to run on other hosts only, so they > - # can't reside in /usr/libexec on the target image. Move to /usr/bin. > - if [ "$("${DIRNAME}" "${__bin}")" = "/usr/libexec" ]; then > - __bindir="${wd}/usr/bin" > - else > - __bindir="${wd}$("${DIRNAME}" "${__bin}")" > - fi > - > "${MKDIR}" -p "${__bindir}" > "${CP}" --preserve=all "${__bin}" "${__bindir}" > -- Stefano ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Remove incorrect special handling of /usr/libexec 2024-08-26 7:55 ` Stefano Brivio @ 2024-08-26 8:20 ` David Gibson 2024-08-26 8:37 ` Stefano Brivio 0 siblings, 1 reply; 7+ messages in thread From: David Gibson @ 2024-08-26 8:20 UTC (permalink / raw) To: Stefano Brivio; +Cc: passt-dev [-- Attachment #1: Type: text/plain, Size: 2310 bytes --] On Mon, Aug 26, 2024 at 09:55:47AM +0200, Stefano Brivio wrote: > On Mon, 26 Aug 2024 16:39:01 +1000 > David Gibson <david@gibson.dropbear.id.au> 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? > 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. > > > [0] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html > > > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au> > > --- > > mbuto | 8 -------- > > 1 file changed, 8 deletions(-) > > > > diff --git a/mbuto b/mbuto > > index a2a8147..5e8ea9c 100755 > > --- a/mbuto > > +++ b/mbuto > > @@ -752,14 +752,6 @@ prog_add() { > > unset IFS > > [ -z "${__bin}" ] && err "Can't source ${1}" > > > > - # Binaries in /usr/libexec are meant to run on other hosts only, so they > > - # can't reside in /usr/libexec on the target image. Move to /usr/bin. > > - if [ "$("${DIRNAME}" "${__bin}")" = "/usr/libexec" ]; then > > - __bindir="${wd}/usr/bin" > > - else > > - __bindir="${wd}$("${DIRNAME}" "${__bin}")" > > - fi > > - > > "${MKDIR}" -p "${__bindir}" > > "${CP}" --preserve=all "${__bin}" "${__bindir}" > > > -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Remove incorrect special handling of /usr/libexec 2024-08-26 8:20 ` David Gibson @ 2024-08-26 8:37 ` Stefano Brivio 2024-08-26 8:47 ` David Gibson 0 siblings, 1 reply; 7+ messages in thread From: Stefano Brivio @ 2024-08-26 8:37 UTC (permalink / raw) To: David Gibson; +Cc: passt-dev On Mon, 26 Aug 2024 18:20:35 +1000 David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Remove incorrect special handling of /usr/libexec 2024-08-26 8:37 ` Stefano Brivio @ 2024-08-26 8:47 ` David Gibson 2024-08-26 8:57 ` Stefano Brivio 0 siblings, 1 reply; 7+ messages in thread From: David Gibson @ 2024-08-26 8:47 UTC (permalink / raw) To: Stefano Brivio; +Cc: passt-dev [-- Attachment #1: Type: text/plain, Size: 2833 bytes --] On Mon, Aug 26, 2024 at 10:37:23AM +0200, Stefano Brivio wrote: > On Mon, 26 Aug 2024 18:20:35 +1000 > David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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. But.. they wouldn't have been in the PATH on the host either, so whatever front end binary is using them must have found them by some other means. > 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. Ah... I guess for qemu-kvm we're intentionally taking what's a support binary on the host and using it as a primary binary on the guest. That's different from the sshd-session case, where it's a support binary in both environments. I'd favour leaving the path of the binary itself alone and explicitly adding a link from /usr/bin for the qemu-kvm case. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Remove incorrect special handling of /usr/libexec 2024-08-26 8:47 ` David Gibson @ 2024-08-26 8:57 ` Stefano Brivio 2024-08-26 9:43 ` David Gibson 0 siblings, 1 reply; 7+ messages in thread From: Stefano Brivio @ 2024-08-26 8:57 UTC (permalink / raw) To: David Gibson; +Cc: passt-dev On Mon, 26 Aug 2024 18:47:27 +1000 David Gibson <david@gibson.dropbear.id.au> wrote: > On Mon, Aug 26, 2024 at 10:37:23AM +0200, Stefano Brivio wrote: > > On Mon, 26 Aug 2024 18:20:35 +1000 > > David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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. > > But.. they wouldn't have been in the PATH on the host either, so > whatever front end binary is using them must have found them by some > other means. If you actually use the front-end binary, sure. The issue is the interpretation of "intended" in the FHS description: /usr/libexec includes internal binaries that are not intended to be executed directly by users or shell scripts. ...not intended on a specific distribution? Or due to their nature? > > 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. > > Ah... I guess for qemu-kvm we're intentionally taking what's a support > binary on the host and using it as a primary binary on the guest. Right, same for kata-agent. > That's different from the sshd-session case, where it's a support > binary in both environments. > > I'd favour leaving the path of the binary itself alone and explicitly > adding a link from /usr/bin for the qemu-kvm case. We could add a link from /usr/bin for all the paths we find in /usr/libexec, then, to keep it more general. But is it really worth the effort compared to just adding /usr/libexec to $PATH on the guest? -- Stefano ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] Remove incorrect special handling of /usr/libexec 2024-08-26 8:57 ` Stefano Brivio @ 2024-08-26 9:43 ` David Gibson 0 siblings, 0 replies; 7+ messages in thread From: David Gibson @ 2024-08-26 9:43 UTC (permalink / raw) To: Stefano Brivio; +Cc: passt-dev [-- Attachment #1: Type: text/plain, Size: 4088 bytes --] On Mon, Aug 26, 2024 at 10:57:12AM +0200, Stefano Brivio wrote: > On Mon, 26 Aug 2024 18:47:27 +1000 > David Gibson <david@gibson.dropbear.id.au> wrote: > > > On Mon, Aug 26, 2024 at 10:37:23AM +0200, Stefano Brivio wrote: > > > On Mon, 26 Aug 2024 18:20:35 +1000 > > > David Gibson <david@gibson.dropbear.id.au> 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 <david@gibson.dropbear.id.au> 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. > > > > But.. they wouldn't have been in the PATH on the host either, so > > whatever front end binary is using them must have found them by some > > other means. > > If you actually use the front-end binary, sure. The issue is the > interpretation of "intended" in the FHS description: > > /usr/libexec includes internal binaries that are not intended to be > executed directly by users or shell scripts. > > ...not intended on a specific distribution? Or due to their nature? Right. I mean, it's kind of necessarily the former, since the distro makes the decision. And that category will include things in the latter as well. > > > 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. > > > > Ah... I guess for qemu-kvm we're intentionally taking what's a support > > binary on the host and using it as a primary binary on the guest. > > Right, same for kata-agent. > > > That's different from the sshd-session case, where it's a support > > binary in both environments. > > > > I'd favour leaving the path of the binary itself alone and explicitly > > adding a link from /usr/bin for the qemu-kvm case. > > We could add a link from /usr/bin for all the paths we find in > /usr/libexec, then, to keep it more general. But is it really worth the > effort compared to just adding /usr/libexec to $PATH on the guest? Fair point, it's not like the mbuto minimal environment needs to be strictly FHS-ishly correct. -- David Gibson (he or they) | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you, not the other way | around. http://www.ozlabs.org/~dgibson [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-08-26 9:43 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-08-26 6:39 [PATCH] Remove incorrect special handling of /usr/libexec David Gibson 2024-08-26 7:55 ` Stefano Brivio 2024-08-26 8:20 ` David Gibson 2024-08-26 8:37 ` Stefano Brivio 2024-08-26 8:47 ` David Gibson 2024-08-26 8:57 ` Stefano Brivio 2024-08-26 9:43 ` David Gibson
Code repositories for project(s) associated with this public inbox https://passt.top/passt This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for IMAP folder(s).