From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 121544 invoked by alias); 21 Feb 2020 12:19:50 -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 121529 invoked by uid 89); 21 Feb 2020 12:19: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=ham version=3.3.1 spammy=incorporated, observe, act 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 12:19:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582287586; 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=ZyQHIMrm4dIdcmfWP4gDVKrxOCnf+8bHana22jCacqE=; b=Te8d2KSuxlZkevx5UodKANGt0K/O+mEl69m2Ywt9pRMrWJX0vVQwihOd+Lu7Lfc751ypKg WKAUX6h9ksBzC8o1KzXZHLIwr7klEhzd/4EhRzl/VNQcKVkOfc02Q7AaeEQNnBD2fFyOcw 9OtKR4BKZv0kn997FHJktxDGmkByAGo= 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-168-cf9eIVntOHqMgIPRsWNPfQ-1; Fri, 21 Feb 2020 07:19:41 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 5EAB4107ACC5 for ; Fri, 21 Feb 2020 12:19:40 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-116-104.ams2.redhat.com [10.36.116.104]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 67B659076D; Fri, 21 Feb 2020 12:19:36 +0000 (UTC) From: Florian Weimer To: Eric Blake Cc: libc-help@sourceware.org, "libguestfs\@redhat.com" Subject: Re: [Libguestfs] alternatives for hooking dlopen() without LD_LIBRARY_PATH or LD_AUDIT? 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> Date: Fri, 21 Feb 2020 12:19:00 -0000 In-Reply-To: (Eric Blake's message of "Tue, 18 Feb 2020 15:31:56 -0600") Message-ID: <8736b4jfop.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00022.txt.bz2 * Eric Blake: > 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? So you want to dlopen nbdkit-vddk-plugin.so and launch a new auditor even if the process so far hasn't used auditing? And the main program (which links agains a library which eventually makes this dlopen call) would not know anything about the existence of this specific plugin and auditing? This isn't currently supported. It's not just that the glibc implementation cannot do it. The audit API (as sketched in ) is not a good fit for late loading where you have never observed open events. It pretty much assumes that auditors are loaded magically *before* program start, so that they can observe all open calls and set up their own data structures along the way. 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? Thanks, Florian