From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from alt12.smtp-out.videotron.ca (alt13.smtp-out.videotron.ca [135.19.0.26]) by sourceware.org (Postfix) with ESMTPS id 052C03857C5A for ; Mon, 23 Nov 2020 14:42:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 052C03857C5A Received: from [192.168.0.100] ([96.20.238.10]) by Videotron with SMTP id hD32kg3dMhH1BhD33kYqS6; Mon, 23 Nov 2020 09:42:34 -0500 X-Authority-Analysis: v=2.3 cv=NIqrBHyg c=1 sm=1 tr=0 a=IvhzMnQCxHlOtQqA98XSUg==:117 a=IvhzMnQCxHlOtQqA98XSUg==:17 a=IkcTkHD0fZMA:10 a=x7bEGLp0ZPQA:10 a=rvM64S1SdSMA:10 a=6Tjk2dYpuFL40dMpM1kA:9 a=QEXdDO2ut3YA:10 Subject: Re: what is the dlopen criterion used to decide if library needs to be loaded? To: Florian Weimer Cc: Daniel Villeneuve via Libc-help References: <878sb5rl2q.fsf@oldenburg2.str.redhat.com> <19c7f6df-e4ff-94e9-1925-305747c1cb8b@gmail.com> <8c3303c9-80e5-597c-334d-5bfbe75301cc@gmail.com> <87y2isbbml.fsf@oldenburg2.str.redhat.com> From: Daniel Villeneuve Message-ID: Date: Mon, 23 Nov 2020 09:42:32 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <87y2isbbml.fsf@oldenburg2.str.redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CMAE-Envelope: MS4wfMRZswOt+Gjox0RD/TeqxqnSYgF3M+2QLTxIYCx+J8zL5OJsIilWO+mH8Wy//4XAIewmXZCk02qgyLtAu1TEUm80HkrPg9nDtzEG8QeMDPwhC44vkrC9 CVz3NphOZhUWoBucxVCoq8sko1ly9Nv5fi1rwWrfxOwatqIjx/n1tRXKfJ73j7ZPWc2G7ksoosvFSEXtDmEBKZiQ21K05ye/1io= X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, KAM_DMARC_NONE, KAM_DMARC_STATUS, NICE_REPLY_A, NML_ADSP_CUSTOM_MED, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP autolearn=no 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 14:42:36 -0000 On 11/23/20 5:39 AM, Florian Weimer wrote: > * 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.  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 for the warning. I understand I was inferring correctness from implementation-defined behavior (vs published spec). Is there a doc on the stable part of dynamic-loading rules regarding a filesystem library name, its  internal soname and already loaded shared libraries? In my case, something about when the argument to dlopen could/will be reused internally without being loaded vs must be loaded anew. I could not find this information except by reading the source code and asking on the list. Regards, -- Daniel Villeneuve