From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30036 invoked from network); 8 Feb 2023 01:36:39 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 8 Feb 2023 01:36:39 -0000 Received: (qmail 5312 invoked by uid 550); 8 Feb 2023 01:36: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 5273 invoked from network); 8 Feb 2023 01:36:35 -0000 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru E4D1D40770A8 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1675820183; bh=kPi7KBn+9jphS2hDjVAzdfDCn0+goYR8oBDj+DqmyOw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=koTk58NkmmZDRMF9+0UskAh5mRS4SzhFxJBjmt51iYqGBHMLnpVwrIZj6clWKca7s KhbGOOHjnBX7bDcY17va67Y7jUOtX8RsJAqxRZBQFRiCkq7EAfY4bMf0YmaO2TJ+Ji ANb3XIIU/mB3a5rIvMsSQi94sHXMwfjrtK+tvohE= MIME-Version: 1.0 Date: Wed, 08 Feb 2023 04:36:23 +0300 From: Alexey Izbyshev To: musl@lists.openwall.com Cc: Colin Cross In-Reply-To: <20230208004906.GR4163@brightrain.aerifal.cx> References: <20230208004906.GR4163@brightrain.aerifal.cx> User-Agent: Roundcube Webmail/1.4.4 Message-ID: X-Sender: izbyshev@ispras.ru Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [musl] Supporting multilib LD_LIBRARY_PATHs On 2023-02-08 03:49, Rich Felker wrote: > On Tue, Feb 07, 2023 at 02:58:37PM -0800, Colin Cross wrote: >> I'm hitting an issue where some test infrastructure is setting >> LD_LIBRARY_PATH to a list that contains both 32-bit and 64-bit >> libraries because it is unsure whether the code under test is going to >> execute 32-bit or 64-bit processes or both. When using musl the >> dynamic loader takes the first library with a matching name and then >> fails to load it if it is for the wrong elf class. >> >> The attached patch verifies the elf machine and class when searching >> the path list, continuing the search if a valid elf header with an >> incorrect machine or class is found. > > While it requires some consideration to ensure that this yields safe & > consistent behavior, I think it at least admits that; I haven't > checked the actual code, but conceptually, it should be equivalent to > treating finding a mismatched-arch library as a conclusive result > whose behavior is searching the remainder of the search path. > > I'm a little bit skeptical of the motivation though. In general, it's > not safe to just set LD_LIBRARY_PATH and run programs that might > invoke other programs, since the math might contain outdated or > mismatched libraries relative to what those other programs might want. > On a system with multiple libcs present, the libraries found could > even be for the wrong one. Really, LD_LIBRARY_PATH should just be set > for invoking a single program (or family of binaries) that ships with > its own versions of libraries or when you're overriding certain > libraries for it, etc. This is contrary to how the environment works, > and one reason it's probably better to use ldso --library-path=... > rather than LD_LIBRARY_PATH when overriding libraries for a particular > program invocation. > It's sometimes convenient to use LD_PRELOAD in conjunction with LD_LIBRARY_PATH to override libc functions in a specific process tree containing binaries for different architectures, e.g. 32-bit/64-bit on x86 systems or native/foreign (run via qemu-user). I don't know how to achieve that with current musl other than by overriding exec*/posix_spawn functions and manually checking the architecture of the binary (and not forgetting to process "#!" for scripts), so I'd be glad to see the proposed functionality in musl. In general, it would still not work on systems with multiple libcs, but I'd expect the mixed-libc case to be much rarer than the mixed-arch one. Alexey