From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101975 invoked by alias); 18 Feb 2020 21:32:11 -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 101958 invoked by uid 89); 18 Feb 2020 21:32:10 -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=incorporated, mere, apis, APIs X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 18 Feb 2020 21:32:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582061527; 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=TbqckgBr3IRv0i4nTmCu1y7ii3IDMIq4X+iV5JKY7Uc=; b=QE7gir35jUwgmdMOMiwbjREFk+Sb/rG6CJBzn4o3eIZ/nAetkLVYM2pWVKZlePtF9WD4rj EdfJdHko90UV/WqvwxbiGIgz9K8OdC44HwXOTlE5DulWz33R/d9IfayKv4zX9DDMp88XpR cH/PrYBsao4bLy9O8X5bKGiRIWdQ3xE= 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-320-R_aqb6LTMMaoX_yrkfVX-g-1; Tue, 18 Feb 2020 16:32:00 -0500 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7DB8CDBF7 for ; Tue, 18 Feb 2020 21:31:59 +0000 (UTC) Received: from [10.3.116.180] (ovpn-116-180.phx2.redhat.com [10.3.116.180]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 25F2E101D486; Tue, 18 Feb 2020 21:31:56 +0000 (UTC) Subject: Re: [Libguestfs] alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT? To: Florian Weimer 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> From: Eric Blake Message-ID: Date: Tue, 18 Feb 2020 21:32: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: <87d0adnt84.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: 7bit X-SW-Source: 2020-02/txt/msg00018.txt.bz2 On 2/17/20 9:12 AM, Florian Weimer wrote: > * Eric Blake: > >> I'm just now noticing that 'man ld' reports that you may pass '--audit >> LIB' during linking to add a DT_DEPAUDIT dependency on a library >> implementing the audit interface, which sounds like it might be an >> alternative to LD_AUDIT for getting a library with la_objsearch() to >> actually do something (but doesn't obviate the need for la_obsearch() >> to be in a separate library, rather than part of the main executable, >> unless a library can be reused as its own audit library...). > > DT_AUDIT support has yet to be implemented in glibc: > > > > > If you go on record saying that you need this, maybe someone will review > the patch. Sorry. 8-( Another followup: nbdkit-vddk-plugin.so is now using a re-exec setup [1], for several reasons: 1. all our other ideas tried so far (such as a dlopen() interposition in the main nbdkit binary) touched more files and required more exported APIs; we managed to get re-exec working with changes limited to just the plugin (other than a minor change to nbdkit to quit messing with argv[] so that /proc/self/cmdline would stay stable - but that did not require a new API). 2. it turns out that overriding dlopen() was insufficient to work around VDDK's setup [2]. It _did_ solve the initial dlopen() performed by VDDK, but that library in turn had DT_NEEDED entries for bare library names, which dlopen() does NOT affect but which la_objsearch() should. 3. for nbdkit, we want to minimize the number of binary files shipped; the re-exec solution works with just the nbdkit binary and the nbdkit-vddk-plugin.so. Any solution that requires a third file to be shipped (be that a shared library providing dlopen, or a LD_AUDIT library, or otherwise) is less palatable than the 2-binary solution that our re-exec solution provides. [1] https://github.com/libguestfs/nbdkit/commit/0c7ac4e655b [2] https://www.redhat.com/archives/libguestfs/2020-February/msg00184.html So with that said, here's a question I just thought of: If your patch for glibc support for DT_AUDIT is incorporated, is it possible to mark a shared library as its own audit library via DT_AUDIT? That is, if nbdkit-vddk-plugin.so can provide entry points for _both_ the nbdkit interface (which satisfies dlopen() from the nbdkit binary) and la_version/la_objsearch() (which satisfy the requirements for use from the audit code in ld.so), _and_ during the compilation of nbdkit-vddk-plugin.so, we marked the library as its own DT_AUDIT entry, would the mere act of dlopen("nbdkit-vddk-plugin.so") from nbdkit be sufficient to trigger audit actions such as la_objsearch() on all subsequent shared loads (whether by dlopen() or DT_NEEDED) performed by nbdkit-vddk-plugin.so and its descendant loaded libraries? Because if so, we would have a use case where a single binary, set up to act as its own audit library, might be sufficient to hook the shared object search path without needing any of environment variable modification, a process re-exec, or a third shipping binary - in which case that would indeed be a nicer solution than the current re-exec solution we committed today (of course, nbdkit would not be able to rely on that solution except on systems with new enough glibc to support DT_AUDIT). I guess even without DT_AUDIT support, I could at least answer the question of whether a single .so can be used to satisfy both dlopen() and LD_AUDIT interfaces at once by setting LD_AUDIT (where the only remaining gap is figuring out when glibc can let DT_AUDIT have the same effect). During my earlier attempts to get a working dlopen() override, I didn't consider any solution that required setting LD_AUDIT, but now that I proved dlopen() override alone was not enough for the case at hand, having to re-exec to set LD_AUDIT is no worse than having to re-exec to set LD_LIBRARY_PATH as a fallback to systems where glibc does not support DT_AUDIT. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org