From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2285 invoked by alias); 14 Feb 2020 22:20:58 -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 2266 invoked by uid 89); 14 Feb 2020 22:20:57 -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=ham version=3.3.1 spammy=strategies, H*MI:sk:39d94f0, H*i:sk:39d94f0, H*f:sk:39d94f0 X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.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, 14 Feb 2020 22:20:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1581718855; 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=wQ64R7JUw3bdXafd5xi2uY4nPmwn2lZfQ/30O4dKTJ0=; b=U+FNkrGkApqyorscyNj/L44VrTdSXrPbj5OJOYE+hsK9bDXWIB9OzYLNoeIGxUdJYwjAJb jvydiH8pjCWGb8u5QeG/6Ei111uLTFiR9Q//D4CabvLNdPQ90ESYssF0XGk4pepUT+yVZs 5YRZ2Nv96VA9Keb3mdfwYGlGsngHZg4= Received: from mail-qv1-f72.google.com (mail-qv1-f72.google.com [209.85.219.72]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-182-Jnw7EDREOR6_T1Z0o9SnMQ-1; Fri, 14 Feb 2020 17:20:45 -0500 Received: by mail-qv1-f72.google.com with SMTP id z39so6663876qve.5 for ; Fri, 14 Feb 2020 14:20:45 -0800 (PST) Return-Path: Received: from [192.168.1.4] (135-23-175-75.cpe.pppoe.ca. [135.23.175.75]) by smtp.gmail.com with ESMTPSA id b7sm4104741qtj.78.2020.02.14.14.20.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 Feb 2020 14:20:43 -0800 (PST) Subject: Re: [Libguestfs] alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT? To: Eric Blake , libc-help@sourceware.org Cc: "libguestfs@redhat.com" References: <8cf57641-c31e-3db5-49af-d9d7407a9cb8@redhat.com> <39d94f06-5793-16b5-1372-df3248924671@redhat.com> From: Carlos O'Donell Message-ID: Date: Fri, 14 Feb 2020 22:20: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: <39d94f06-5793-16b5-1372-df3248924671@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-02/txt/msg00008.txt.bz2 On 2/14/20 4:29 PM, Eric Blake wrote: > On 2/14/20 1:02 PM, Eric Blake wrote: > >> Writing my own dlopen() wrapper directly in nbdkit seems like a >> non-starter (my override has to come from a shared library before >> it can replace the shared version that would be imported from -ldl, >> at least for all subsequent shared library loads that want to bind >> to the override). > > Maybe I spoke too soon. I've tried another approach that looks like > it will do what I want: put my shim dlopen() in a shared library, but > link nbdkit against that shared library PRIOR to -ldl (so that name > lookup for dlopen resolves there first). The shim library in turn > depends on -ldl so that dlsym(RTLD_NEXT, "dlopen") still lets me get > to the real dlopen. And by linking it directly into nbdkit, rather > than into the nbdkit-vddk-plugin.so that gets loaded later, the first > bound dlopen() in use for all subsequent loads is from my shim. It's > still a bit less clean than I'd like (it requires tighter coupling > between nbdkit and nbdkit-vddk-plugin.so than what used to exist), > but the fact that it works without dlmopen() or LD_LIBRARY_PATH is in > its favor. I'm now polishing up the experiment, and will post the > patch when it's ready. I think that's the best solution you're going to get. The alternatives (LD_LIBRARY_PATH, direct loader invocation, dlmopen) all have limitations that aren't helpful to your particular design. You have design strategies that look like this: - Move the object higher in the search order at link time (interposition) - Investigate static link order. - Investigate dynamic loader search order - Change what object is searched for - LD_LIBRARY_PATH, DT_RPATH, DT_RUNPATH, etc. - LD_AUDIT with la_objsearch() Your "shim dlopen()" is a case of moving the static link order around to ensure your shim is used first. -- Cheers, Carlos.