With an explicit loader invocation, the loader adds the main executable name (which is passed to the main function as argv[0]) to l_libname of the main map. This is not what happens in default mode. There, the string "" is used instead. If possible, we should align the behavior for both modes, so that glibc testing without hardcoded paths becomes more realistic.
The master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=23d2e5faf0bca6d9b31bef4aa162b95ee64cbfc6 commit 23d2e5faf0bca6d9b31bef4aa162b95ee64cbfc6 Author: Florian Weimer <fweimer@redhat.com> Date: Thu Aug 15 14:37:50 2019 +0200 elf: Self-dlopen failure with explict loader invocation [BZ #24900] In case of an explicit loader invocation, ld.so essentially performs a dlopen call to load the main executable. Since the pathname of the executable is known at this point, it gets stored in the link map. In regular mode, the pathname is not known and "" is used instead. As a result, if a program calls dlopen on the pathname of the main program, the dlopen call succeeds and returns a handle for the main map. This results in an unnecessary difference between glibc testing (without --enable-hardcoded-path-in-tests) and production usage. This commit discards the names when building the link map in _dl_new_object for the main executable, but it still determines the origin at this point in case of an explict loader invocation. The reason is that the specified pathname has to be used; the kernel has a different notion of the main executable.
Fixed in glibc 2.31.
The fix is incomplete because it does not cover PIE. Patch posted: https://sourceware.org/ml/libc-alpha/2019-08/msg00623.html
The master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=2b26b084e4e4ba58a2ff9f8f8f14c9bca506bd59 commit 2b26b084e4e4ba58a2ff9f8f8f14c9bca506bd59 Author: Florian Weimer <fweimer@redhat.com> Date: Fri Oct 4 21:22:54 2019 +0200 elf: Never use the file ID of the main executable [BZ #24900] If the loader is invoked explicitly and loads the main executable, it stores the file ID of the main executable in l_file_id. This information is not available if the main excutable is loaded by the kernel, so this is another case where the two cases differ. This enhances commit 23d2e5faf0bca6d9b31bef4aa162b95ee64cbfc6 ("elf: Self-dlopen failure with explict loader invocation [BZ #24900]"). Reviewed-by: Carlos O'Donell <carlos@redhat.com> Reviewed-by: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
The master branch has been updated by Florian Weimer <fw@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=7d3db434f910c23591f748a6d0ac3548af1048bb commit 7d3db434f910c23591f748a6d0ac3548af1048bb Author: Florian Weimer <fweimer@redhat.com> Date: Thu Oct 17 08:51:21 2019 +0200 Rename and split elf/tst-dlopen-aout collection of tests From the beginning, elf/tst-dlopen-aout has exercised two different bugs: (a) failure to report errors for a dlopen of the executable itself in some cases (bug 24900) and (b) incorrect rollback of the TLS modid allocation in case of a dlopen failure (bug 16634). This commit replaces the test with elf/tst-dlopen-self for (a) and elf/tst-dlopen-tlsmodid for (b). The latter tests use the elf/tst-dlopen-self binaries (or iconv) with dlopen, so they are no longer self-dlopen tests. Tested on x86_64-linux-gnu and i686-linux-gnu, with a toolchain that does not default to PIE.
Florian, has this bug being fixed by 2b26b084e4e4ba58a2ff9f8f8f14c9bca506bd59?
Yes, it's fixed in glibc 2.31 as far as I can see.