From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 0970F3850417 for ; Mon, 23 Nov 2020 10:39:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0970F3850417 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-507--0zpqmlzN5W06B0PdEaJ2g-1; Mon, 23 Nov 2020 05:39:33 -0500 X-MC-Unique: -0zpqmlzN5W06B0PdEaJ2g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 886555205; Mon, 23 Nov 2020 10:39:32 +0000 (UTC) Received: from oldenburg2.str.redhat.com (ovpn-112-141.ams2.redhat.com [10.36.112.141]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D7CC45C1BD; Mon, 23 Nov 2020 10:39:31 +0000 (UTC) From: Florian Weimer To: Daniel Villeneuve Cc: Daniel Villeneuve via Libc-help Subject: Re: what is the dlopen criterion used to decide if library needs to be loaded? References: <878sb5rl2q.fsf@oldenburg2.str.redhat.com> <19c7f6df-e4ff-94e9-1925-305747c1cb8b@gmail.com> <8c3303c9-80e5-597c-334d-5bfbe75301cc@gmail.com> Date: Mon, 23 Nov 2020 11:39:30 +0100 In-Reply-To: <8c3303c9-80e5-597c-334d-5bfbe75301cc@gmail.com> (Daniel Villeneuve's message of "Sat, 14 Nov 2020 17:52:54 -0500") Message-ID: <87y2isbbml.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2020 10:39:37 -0000 * Daniel Villeneuve: > On 11/13/20 5:18 PM, Daniel Villeneuve wrote: >> On 11/13/20 4:41 PM, Florian Weimer wrote: >>>> In the end, I've rebuilt the library using the same name (not being >>>> sure whether the inode would be the same or not), and before dlopen, I >>>> create a hard link with a new unique name on the library and use that >>>> as arg to dlopen (and then delete the hard link). >>>> >>>> Is this a safe way to ensure a newly built library is really loaded? >>> It depends on what the soname of the library is.=C2=A0 If you set it to= a >>> fixed value, the new library may be opened, but not loaded eventually >>> because the soname is already known to the system. >> >> This internal test about soname (dlopen skipping loading a library) >> is new to me. So loading two different library files, with different >> names, could end up in skipping the second load because of same >> soname? My tests show that even with the same soname, dlopen/dlsym >> use the new library (loaded with the unique name). >> >> My understanding of ld -hSONAME is for registering at link-time in an >> executable which arg to use for an eventual dlopen. Not sure about >> the connection with calling dlopen on a specific path... > > I extended my search in glibc source from dlfcn to elf, and found in > elf/dl-load.c (_dl_map_object) the part that compares the name passed > to dlopen and previously registered sonames. > > Based on that, I could trigger the problem you allude to above, by > using a specially crafted soname for "ld -hSONAME" that ends up > matching a unique name I will generate in the future: in this case, > the library with this specific unique name is not loaded. > > This explains my successful tests as well, since the unique names > passed to dlopen are different from any soname used before, so the > test in _dl_map_object necessarily fails. There are some suggestions that we should not load an object if its soname matches one already known to the system. Unfortunately I can't find the patch reference right now. If we make this change in glibc, I believe your application would behave differently. Thanks, Florian --=20 Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'N= eill