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 A585022FCF for ; Wed, 7 Feb 2024 20:10:45 +0100 (CET) Received: (qmail 22196 invoked by uid 550); 7 Feb 2024 19:07:58 -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 22135 invoked from network); 7 Feb 2024 19:07:58 -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=1707333032; x= 1709147433; bh=1VN7sWKtIbwSNdxFLc81d55hAlG5WFIeEF9Q0tEvJew=; b=c xxkCZeR83Lf/3EfbL6eDFNAiywJ8YU36qVKUwcV32OwEJtKWCGgVDGJfaA3fD5dk q3sZU6tI+6YwkReqdc8JV0VW+y6S7T3Bh2xf540xCMvgEZ8ckQA+3JZvoocN7yJn OoQ7tqFLvNoDIeawtMp0jZ5EI5zzhHZiuv/GxRnEz+6DMZa89kn8ghqow1Vk8s7s 3slT2wAz2m8y01XfIPlixAY+NWxJn1KfSW6Y8YAMQnhM02O0rIVw6yCcA9duOBCN F+k5jhyblCd5Bxr4nWikE0ouQNtJ27ch9Mhed+zEQ8Lh57IwdIAM7nuZ7k0JHNaa NZAcihFcU7aVlLk0W6IuQ== X-Virus-Scanned: Debian amavisd-new at fripost.org Date: Wed, 7 Feb 2024 20:10:09 +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: <20240207173023.GX4163@brightrain.aerifal.cx> Subject: Re: [musl] [PATCH 1/1] ldso: continue searching if wrong architecture is found first Dear Rich, On Wed, Feb 07, 2024 at 12:30:24PM -0500, Rich Felker wrote: > On Tue, Feb 06, 2024 at 05:22:43PM -0800, Markus Mayer wrote: > > When LD_LIBRARY_PATH is being used, the shared library loader may end up > > finding a shared library with the correct name but from a wrong > > architecture. This primarily happens when a 32-bit / 64-bit mismatch > > occurs. > > > > Rather than giving up immediately and aborting, the shared library > > loader should continue to look in all known locations for a matching > > library that may work. > > I don't think the concept is objectionable, but the implementation I wonder how the loader would distinguish between "right" and "wrong" if there are multiple libraries differing for example only in some minor build option - which difference still can be crucial for the actual application or for other used libraries? In other words: LD_LIBRARY_PATH is inherently unsafe when the applications can execute other binaries than prepared by the same party, on a system not managed by the same party. Is it really worth to make LD_LIBRARY_PATH "more usable", but still unsafe? 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. Are there any practical cases where the overhead of an extra execve() of a small wrapper would be a noticeable problem? > If you think there are less invasive ways to do this, I'd be happy to > hear other ideas too. The least invasive way might be to avoid introducing such support? My perspective reflects years of handling third party applications and the consequences of their use of LD_LIBRARY_PATH. This works - *mostly*. At the same time, building and freely mixing applications linked to a plethora of simultaneously available versions and instances of libraries, this worked without any problems ever, thanks to the loader with --library-path. AFAICS, reliance on checks in the loader would never provide the same level of robustness, ease and flexibility. Thanks for musl, regards, /i262jq