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=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 8AFFD290FA for ; Wed, 7 Feb 2024 20:53:24 +0100 (CET) Received: (qmail 27875 invoked by uid 550); 7 Feb 2024 19:50:37 -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 27843 invoked from network); 7 Feb 2024 19:50:37 -0000 Date: Wed, 7 Feb 2024 19:51:54 +0000 (UTC) From: Thorsten Glaser X-X-Sender: tg@herc.mirbsd.org To: musl@lists.openwall.com In-Reply-To: Message-ID: References: <20240207012247.1121273-1-mmayer@broadcom.com> <20240207012247.1121273-2-mmayer@broadcom.com> <20240207173023.GX4163@brightrain.aerifal.cx> Content-Language: de-Zsym-DE-1901-u-em-text-rg-denw-tz-utc, en-Zsym-GB-u-cu-eur-em-text-fw-mon-hc-h23-ms-metric-mu-celsius-rg-denw-tz-utc-va-posix MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Subject: Re: [musl] [PATCH 1/1] ldso: continue searching if wrong architecture is found first i262jq@0w.se dixit: >I wonder how the loader would distinguish between "right" and "wrong" >if there are multiple libraries differing for example only in some minor That is precisely what we wondered about for the time_t-64-on-ILP32 transition in Debian. >build option - which difference still can be crucial for the actual >application or for other used libraries? tl;dr: random build options cannot be distinguished. You have the flags in the ELF header, which have CPU architecture and bitness, and (other than x32 (amd64ilp32) and arm64ilp32, from there on it gets machine-dependent as you need to define per-architecture ABI flags, e.g. EABI vs. old ABI or MIPS o32 vs n32 vs n64. So this will always be some kind of system-global at least, if not world-global, thing, not something for the odd application or admin to decide. >Is it really worth to make LD_LIBRARY_PATH "more usable", but still unsafe= ? I still think so. >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? >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. bye, //mirabilos --=20 =E2=80=9ECool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.=E2=80=9C =09-- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: =E2=80=9C[=E2=80=A6]uhr.gz is a reason to install mksh on every system= =2E=E2=80=9D)