From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 1D7CE2C8B1 for ; Thu, 8 Feb 2024 16:53:26 +0100 (CET) Received: (qmail 1194 invoked by uid 550); 8 Feb 2024 15:50:36 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 1162 invoked from network); 8 Feb 2024 15:50:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=x.fripost.org; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=9df9cdc7e101629b5003b587945afa70; t=1707407592; x= 1709221993; bh=qh7C8sXYtPFwVeAyVdk+LEw6osSR5pN6BxixC9JqmIc=; b=n GqBb2MwVjfUCI47Jske1JFOKPyCmKCCUWtxKA2QhGplwlIZmP3SWMlMPtRnjPCie 4v4T50eadXfNYsdR2jNtKJzTrPgvv30vLwl22WO6KoUGUqowCkjuk2/5Pk47cPwH NWAItMXcVFgrDJBuZSRHr4d38WYnqP7zKPsgjup8R+l20ZdmTQKnb6M4xKiknXDX JCn+Tlz7oUAsLpxD1Zh/A/GZtSw54nGuXAv74AlGgjQ7abNYw95VHsCaLvTNIkpE 3gZRpICNk124W6poQqTX8cwYx0ZhEf7UrjDaIZXC4mXzBpTsdopipS4tgK5sGXkK KNyZTYk2nLOSC64+fR6RA== X-Virus-Scanned: Debian amavisd-new at fripost.org Date: Thu, 8 Feb 2024 16:52:53 +0100 From: i262jq@0w.se To: musl@lists.openwall.com Message-ID: References: <20240207012247.1121273-1-mmayer@broadcom.com> <20240207012247.1121273-2-mmayer@broadcom.com> <20240207173023.GX4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [musl] [PATCH 1/1] ldso: continue searching if wrong architecture is found first On Wed, Feb 07, 2024 at 07:51:54PM +0000, Thorsten Glaser wrote: > i262jq@0w.se dixit: > >To the contrary, relying on the explicit loader in a wrapper is totally > >safe, because the path to the libraries is not inherited at any later > >exec. > > What if the first binary you run is not the one that needs to get the > changed library path, but the binaries it runs? Only starters/wrappers shall be in the PATH or otherwise run. Not any application executables directly. Every wrapper sets the right library path for its binary. > >Are there any practical cases where the overhead of an extra execve() > >of a small wrapper would be a noticeable problem? > > It may be very hard to get these into the right places. Why hard? You do not package software without knowing what are its executables. To replace them with wrappers is a trivial task, or rather to put the wrappers separately, in another file tree or a directory to be used via PATH or directly. If the software is to be used from locally varying paths, you may choose to generate wrappers at "installation"/"file-tree-relocation" stage or otherwise just let your pre-made wrappers examine a _package_specific_ environment variable - resulting in all the semantics of LD_LIBRARY_PATH, but in a totally safe fashion. In other words, I do not see this as a task for the loader (who generally does *not* have all the relevant information, only the limited data from elf), but as a task for the packaging, with an available solution of low cost and complete reliability. Regards, /i262jq