From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48164 invoked by alias); 21 Feb 2020 20:21: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 48153 invoked by uid 89); 21 Feb 2020 20:21:49 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=ORIGIN, agreements X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-1.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Feb 2020 20:21:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582316506; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=8B9VvxlmB01vfyLjQK9mhYDj9uuVnhqx4eLIgK3X6Zc=; b=hXzMxnA9Q1Em0QbjD23K3AEmhqr2EGNZbZvDXEzMoRRBHNIBnMHl8bje45jWvyubXmPXuh KSGn6ss36XOKWeZRbZwxdY/WASVweQgX8LNWLhfrQI+WRyKubo9zuMkjyGs+Z7RbJ6SFPS 5YNMAuRedqc5MQLuiLry7peJiXcaUTY= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-36-kaApP7xhMFChTg-Dpi88uw-1; Fri, 21 Feb 2020 15:21:40 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9CBCF801F8C for ; Fri, 21 Feb 2020 20:21:39 +0000 (UTC) Received: from [10.3.116.90] (ovpn-116-90.phx2.redhat.com [10.3.116.90]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 473865C105; Fri, 21 Feb 2020 20:21:36 +0000 (UTC) Subject: Re: [Libguestfs] alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT? To: Florian Weimer , "Richard W.M. Jones" Cc: libc-help@sourceware.org, "libguestfs@redhat.com" References: <8cf57641-c31e-3db5-49af-d9d7407a9cb8@redhat.com> <39d94f06-5793-16b5-1372-df3248924671@redhat.com> <3ee96b3f-231b-737f-299a-4406f108c30f@redhat.com> <87d0adnt84.fsf@oldenburg2.str.redhat.com> <8736b4jfop.fsf@oldenburg2.str.redhat.com> <20200221145132.GK7304@redhat.com> <87d0a8dlyp.fsf@oldenburg2.str.redhat.com> From: Eric Blake Message-ID: Date: Fri, 21 Feb 2020 20:21:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <87d0a8dlyp.fsf@oldenburg2.str.redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-SW-Source: 2020-02/txt/msg00029.txt.bz2 On 2/21/20 9:00 AM, Florian Weimer wrote: > * Richard W. M. Jones: >=20 >> On Fri, Feb 21, 2020 at 01:19:34PM +0100, Florian Weimer wrote: >>> I think what confuses me is that keep talking about a single binary, but >>> clearly there is this separate vddk DSO, and there is talk of plugins. >>> So it seems to me that multiple files are involved already? >> >> nbdkit is a standalone binary that happens to be able to load plugins >> from a well-known path, eg nbdkit-vddk-plugin.so. nbdkit knows the >> path for plugins, and there's a wrapper allowing it to get local >> plugins even when it's still in the build directory. Adding another >> file would mean another path (or overloading the meaning of the plugin >> path) and just makes the whole thing more fragile and complex. >> >> Having said all that, what would also solve this is either an API for >> updating LD_LIBRARY_PATH after the program has started; or making >> setenv ("LD_LIBRARY_PATH",...) DTRT*; or some kind of dlopen() variant >> which takes a library path as an extra parameter. >=20 > Have you tried adding DT_RUNPATH or DT_RPATH to nbdkit-vddk-plugin.so Post-processing an existing closed-source .so shipped from an external=20 vendor might have negative consequences - while it may be possible to=20 modify the ELF image to add a DT_RUNPATH entry or modify the DT_NEEDED=20 entries to use anchored names based on $ORIGIN rather than bare names,=20 there's no telling if such modification would be in violation of=20 agreements or even cause failure to load if the proprietary code is=20 using shenanigans like validating a checksum of shipped binaries to=20 detect tampering. > Or does the path have to be chosen dynamically? So, since we cannot fix the existing product, and have no idea if/when=20 the vendor will release an updated version that has saner libraries, a=20 dynamic search path is the only option to getting their product to load=20 (but whether that is done by LD_LIBRARY_PATH, LD_AUDIT, pre-loading=20 libraries, or something else, is where we have a bit more control). >=20 > If you merely want to prevent loading of libstdc++.so or libcrypto.so by > vddk, it may be possible to explicitly dlopen DSOs of that name before > loading vddk. But there is an existing bug where we do not duplicate > properly on soname alone, so we may have to fix that first. The problem then becomes "given an arbitrary libvixDiskLib.so, how do we=20 determine the dependency of bare libraries it would want to load so that=20 we can pre-emptively load those libraries by direct path name first".=20 My re-exec solution was nice - it works for all versions of VDDK.=20 Whereas with scraping the binary to see what DT_NEEDED entries it has is=20 a bit more image-specific: for example, VDDK 5.5.5 loads=20 "libcrypto.so.1.0.0", VDDK-6.5 loads "libcrypto.so.1.0.2". I don't want=20 to hard-code any of those library names into nbdkit-vddk-plugin.so,=20 because that would needlessly tie the open source program into a=20 specific VDDK release, instead of working with all of them. However, if=20 it is easy enough to compute our own topological sort of DT_NEEDED for a=20 given VDDK .so, and then pre-load in leaf-first order, so that by the=20 time we finally get around to dlopen()ing libvixDiskLib.so and calling=20 its init function, then all of the subsequent dlopen()s performed by=20 VDDK code will succeed right off the bat because the library has already=20 been loaded in memory. Or at least, that's what I'm hoping your=20 suggesting. And if we do that, it would avoid the need to re-exec with=20 LD_LIBRARY_PATH set. --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org