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=ej9F2vbG; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id 69CB55A004C for ; Mon, 26 Aug 2024 10:51:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202408; t=1724662310; bh=pL2aQ53XDD8Q4SDWJQWLE1hbWXpEEpk25iZ61vm7Gos=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ej9F2vbG5JnARjn5McnL+eDguHd9VbfOIcOie0+uD+FY89JaJ13SbDeuzsMobb1bH YnM8/BultFgdYA4YcSIV0r01n16vCz/gk/haa+R050GJ2Vc9Zbb95lXCfcA80oDHZ1 ozRDHAJQzb6sqXBjgddzSHiqjxPMbRCyywKpqKYqF9tWRx7P4QLXn0+DO5GclvnmEN sKPb0MxgU2jktatz8I73xogu4mzid+GXtf3rf/MRUmLeYh9G7beMr+Ei7+24cBpdDm iLLPFO0Hvp3vSA1p30MXFH0jkgoJrhU+tWw7DzUB0GYqF/v06+RJmOJfAd74DThW3X 91jHM4rrG7REg== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4Wsktt3qjCz4x81; Mon, 26 Aug 2024 18:51:50 +1000 (AEST) Date: Mon, 26 Aug 2024 18:47:27 +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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lzMuOyyt9iPA/9hF" Content-Disposition: inline In-Reply-To: <20240826103723.60e04eb6@elisabeth> Message-ID-Hash: CKB63FLSW4ORL6IAZH3YBJJ6QWZFQAVS X-Message-ID-Hash: CKB63FLSW4ORL6IAZH3YBJJ6QWZFQAVS 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: --lzMuOyyt9iPA/9hF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > > On Mon, 26 Aug 2024 16:39:01 +1000 > > > David Gibson wrote: > > > =20 > > > > The statement in the comment about /usr/libexec being only for runn= ing on > > > > other hosts simply isn't true, neither in practice nor according 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 those= in > > > > (explicitly FHS permitted) subdirectories under /usr/libexec. =20 > > >=20 > > > So, this change breaks the two cases I needed to cover with this, whi= ch > > > are /usr/libexec/kata-agent in general, and /usr/libexec/qemu-kvm on > > > RHEL 9. =20 > >=20 > > Huh.. why? >=20 > 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. >=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 > 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. --=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 --lzMuOyyt9iPA/9hF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmbMQR4ACgkQzQJF27ox 2GfshxAAmWfKHWD4MLBWgFdpzlXLRoXkfMNsubr93Z6n2n3eRDR5T7FjUuke3L4k Hbx/mBqgqejFGoh5Nz/Zk7660XavfusYraKjKjGc9LqqTT//UnS/u/U3Mf0hkFxs XZI3IQx9DGrpLgRQ2M6xkSRfO/1lGXBMQTtRuULASDhFnyysz8+ps+Q+TXRcFCsM vaIjqFmXk/FVYNqs9TQk6LEXiKsdq47ss4tuSlt2YhEoy/471txgx7NVawFDY0Os zi4PMX/xg/vUOzKHSOVVCSPMVUj7Ox7Pfeq3NlGkwyz8aV8+WPdQ3BTxJyzAge9M n5ekFxaFFa3cXP6G2QpAniiY93HYSiBe2ilBd/4ucDIpK8eKmFbdRIhmrtGU/Pq5 UDPGZQugw3MPE+n0vFbo04CpbE19AR3ibR+NwvShzuhcuhig8ZeqlPzeHV2dUHXE 0eG7ljUUTJt3EK7cpRS0mFUlWf7VoJHh7pVJpgtMHowZ4W3rKgSEUuiwUntWgYVV rIWxaO6Q332qqalwGyYXcgAgXkXhdIqX3IzDKUVEzPh3nNKSy8VgijK4Qx6ne7Ma gZmEtpGEjlFcQo2IIdXkwP5Azo9Rl2yGXPAsRtjK6lBydHJ6jByaehHihlizVPI2 2MvbeL3HAWdhR93BYWuIVF5WPEC2AsIB65UKGC827QUTX0EplEo= =a2fJ -----END PGP SIGNATURE----- --lzMuOyyt9iPA/9hF--