From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202408 header.b=OfyArQNw; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 08D755A004C for ; Mon, 26 Aug 2024 11:43:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202408; t=1724665406; bh=Xgs57yVG7mqV+mv6l1A8LFyHtBTu1PAVJHxJaC/4ydQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OfyArQNw9fkYp2mPo/kN2dnjcvPAU7EbvJhxxqLe5oyppSEm45Q/nFSUvUkX5QbSp pOm8rv0w1ziCVTFGYhQHNQg+3GRzTPDCiL9T7K3fR6pdKoAfWdI7fw7VJ/tXDIRIx5 1oj+Ng7ekUOx0h9wiUlhZkMNfkDI0iIKRvuc0pZrmF4bXr3F0QW/FpEXXgr6mbf+eB PTRdOtE2bJFWMD5hW6yFPhl2rt+U8nS7/aSK7tR78pHjLPYRwxrAkaRotr98cMejbb 0LaOqLG2OqBmwfLBVEH6wgSNiGuBE5SUqPoyglKhJidOIRoZY4GlNAxGTdhN3Dg4IJ PgKPZhnsQKqdA== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4Wsm2Q1kqNz4x42; Mon, 26 Aug 2024 19:43:26 +1000 (AEST) Date: Mon, 26 Aug 2024 19:43:23 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH] Remove incorrect special handling of /usr/libexec Message-ID: References: <20240826063901.590640-1-david@gibson.dropbear.id.au> <20240826095547.43a050fd@elisabeth> <20240826103723.60e04eb6@elisabeth> <20240826105712.3f4ce3a8@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tY/MLLyiERK9y5ul" Content-Disposition: inline In-Reply-To: <20240826105712.3f4ce3a8@elisabeth> Message-ID-Hash: 3IOH4U3DIPBG6W26B4ZHFJZGZ4KDFHHP X-Message-ID-Hash: 3IOH4U3DIPBG6W26B4ZHFJZGZ4KDFHHP X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --tY/MLLyiERK9y5ul Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Aug 26, 2024 at 10:57:12AM +0200, Stefano Brivio wrote: > On Mon, 26 Aug 2024 18:47:27 +1000 > David Gibson wrote: >=20 > > On Mon, Aug 26, 2024 at 10:37:23AM +0200, Stefano Brivio wrote: > > > On Mon, 26 Aug 2024 18:20:35 +1000 > > > David Gibson wrote: > > > =20 > > > > On Mon, Aug 26, 2024 at 09:55:47AM +0200, Stefano Brivio wrote: =20 > > > > > On Mon, 26 Aug 2024 16:39:01 +1000 > > > > > David Gibson wrote: > > > > > =20 > > > > > > The statement in the comment about /usr/libexec being only for = running on > > > > > > other hosts simply isn't true, neither in practice nor accordin= g to the > > > > > > FHS spec[0]. =20 > > > > >=20 > > > > > 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. > > > > > =20 > > > > > > Furthermore this logic didn't even handle it correctly, since > > > > > > it would only handle binaries _directly_ in /usr/libexec, not t= hose in > > > > > > (explicitly FHS permitted) subdirectories under /usr/libexec. = =20 > > > > >=20 > > > > > 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. =20 > > > >=20 > > > > Huh.. why? =20 > > >=20 > > > Because they're not in PATH on the guest, so we can't execute them. = =20 > >=20 > > 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. >=20 > If you actually use the front-end binary, sure. The issue is the > interpretation of "intended" in the FHS description: >=20 > /usr/libexec includes internal binaries that are not intended to be > executed directly by users or shell scripts. >=20 > ...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 implement= ed > > > the $FIXUP mechanism, and I needed to run kata-agent as init. > > >=20 > > > But now that $FIXUP is available, that's probably less invasive. > > > =20 > > > > > What does it fix? =20 > > > >=20 > > > > 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. =20 > > >=20 > > > 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 t= he > > > guest. =20 > >=20 > > 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. >=20 > Right, same for kata-agent. >=20 > > That's different from the sshd-session case, where it's a support > > binary in both environments. > >=20 > > I'd favour leaving the path of the binary itself alone and explicitly > > adding a link from /usr/bin for the qemu-kvm case. >=20 > 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. --=20 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 --tY/MLLyiERK9y5ul Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmbMTjoACgkQzQJF27ox 2GdT+Q//WBj6ExIG16CyiQxxgyiovNmz3mTJF7a/1gB1Avp4VZ69xMlSpeneg/xQ 0E+I7yfRBs7mXIUPnPGEPeI6XASLYJeDh+u0xCi/x4LgLkawIV31muG7U83jQxWm l87ogtJiGO3Nif5bMyYYy1jr5tfp0HZJv+B5LKuQFLlG2a1Bs8Ce5pIDouFqPmc7 +K8wlOMNndHnAkTm0yBVvPusG+jYuBpgrhKHvaSQyyI1cCJTOKz1GQk40xwnzHc6 KJ+S5mCYLGMrxyPuas9yzNOMVCXrDUJh7zkSUd0+cilxukNZI+CS1h4jbjbBl+no gSdOcCj7NTsy9KelVfaWkoKt5rfZkOu5GBTxXRlBy7P8qsmxqEPPw4IGm4HQGFO1 3Yrc5WhBH5UlTzLk6mpLxOeRz4Ylzj4JQGPE5ZfyTwGF7AP5C49UeP/Mv+V7vMs7 LgZGct6m0OdooLhlOP4cbe1uiNg/CM2MHT3W15rU8CKBPWVXkfkvtvxSisDhPBUO yl2f4CR7isgx2QDhXQTS+27dfSJeEPHAhGXo6S+AobvN244N9qMSbM18mlZBoPWc ieHxXPD5m9I2lw1OYzoN/9TTtKjjqmV5vaM1gBKrM10TE+jgR8MaNeQcFd5fT/e7 bPcf52wuA2SFOI9jsx00bZizLwwNXBekkV0n1tlzh+Z6VBewMFQ= =WqQp -----END PGP SIGNATURE----- --tY/MLLyiERK9y5ul--