From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20073 invoked by alias); 7 Jun 2019 20:46:49 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 20052 invoked by uid 89); 7 Jun 2019 20:46:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.1 spammy=H*RU:209.85.160.193, HX-Spam-Relays-External:209.85.160.193, H*f:sk:CAH8yC8, H*i:sk:6mMHJt6 X-HELO: mail-qt1-f193.google.com Received: from mail-qt1-f193.google.com (HELO mail-qt1-f193.google.com) (209.85.160.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 07 Jun 2019 20:46:48 +0000 Received: by mail-qt1-f193.google.com with SMTP id j19so3838413qtr.12 for ; Fri, 07 Jun 2019 13:46:47 -0700 (PDT) Return-Path: Received: from [192.168.1.4] (192-0-145-99.cpe.teksavvy.com. [192.0.145.99]) by smtp.gmail.com with ESMTPSA id h128sm1701040qkf.14.2019.06.07.13.46.45 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 13:46:45 -0700 (PDT) Subject: Re: How to set a system-wide library path policy? To: noloader@gmail.com References: Cc: Binutils , libc-help From: Carlos O'Donell Message-ID: Date: Fri, 07 Jun 2019 20:46:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-06/txt/msg00002.txt.bz2 On 6/7/19 10:53 AM, Jeffrey Walton wrote: > I'm having trouble figuring out how to setup library path policy on Fedora 29. The system loader is in glibc. Adding libc-help to the CC. > I need to articulate to the system loader: > > 1. programs in /bin must only link to libs in /lib64 > 2. programs in /usr/bin must only link to libs in /usr/lib64 > 3. programs in /usr/local/bin may use libraries in /usr/local/lib64 or > /usr/lib64 OK. > As far as I know, the distro supplies (1) and (2). They know nothing > about my libraries in /usr/local. When the distro is ready, it will > push updated programs and libraries as needed. The distro binaries > should not use my libraries. Why would your distro binaries use your libraries? Such libraries are not present at static link time when they are built in the Feodra builders. The only reason your distro libraries would be used is if you used LD_LIBRARY_PATH that pointed to them, in which case you would be altering the global search order. > The reason I need it is, the libs in /usr/local have various > compatibility problems. I've had bash, grep and sed from /usr and > /usr/bin die because I built a library in /usr/local with a sanitizer, > and the program or another library had undefined behavior or a memory > error that surfaced. It basically makes the system unusable. How did your system binaries end up using libraries from /usr/local/lib64? Did you use LD_LIBRARY_PATH? > Additional problems I have managed to side-step so far include > removing unaligned access in /usr/local programs and libraries. > Sometimes that involves modifying a struct. Different stuct > definitions are surely going to cause problems. It will cause problems. > How do I tell the system loader to only use distro libraries for > distro binaries? Don't run them with options that cause the dynamic lodaer to search for libraries in alternate locations? Alternative, and this is a heavy hammer option, you use the LD_AUDIT mechanism and write an audit module that rewrites the lookup paths for system binaries to *never* look in /usr/local-anything. See `man rtld-audit`, and la_objsearch(). -- Cheers, Carlos.