This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/15022] New: Global-scope dlopen issues in static executables
- From: "macro at linux-mips dot org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 16 Jan 2013 22:40:20 +0000
- Subject: [Bug dynamic-link/15022] New: Global-scope dlopen issues in static executables
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=15022
Bug #: 15022
Summary: Global-scope dlopen issues in static executables
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: dynamic-link
AssignedTo: unassigned@sourceware.org
ReportedBy: macro@linux-mips.org
Classification: Unclassified
We have two issues with dlopen [1] issued from static executables when
the global scope is accessed.
First, an attempt to add a dynamic shared module to the global scope
(i.e. with RTLD_GLOBAL requested) crashes like this:
Program received signal SIGSEGV, Segmentation fault.
add_to_global (new=0x49ef60) at dl-open.c:101
101 ns->_ns_global_scope_alloc
This is because at this point in static executables no global search list
data structure has been initialised and as result the _ns_main_searchlist
member of _dl_ns[LM_ID_BASE] (the initial namespace) is null.
Second, an attempt to access the global scope itself (i.e. by using a
null file name pointer) fails with an obscure error like:
/path/to/dir/: cannot read file data: Is a directory
(that can be retrieved with dlerror), where /path/to/dir/ is the first
directory searched according to the dynamic load engine's shared module
lookup policy. This is because the null file name pointer is internally
converted to an empty string, that is in turn looked for and then opened
in the directories examined. Of course that succeeds -- the directory
itself is opened, but then the engine gets confused by the outcome and
bails out. The use of an empty string works in dynamic executables,
because for them the dynamic loader has already prepared a link map
referring to a file whose name is empty -- which, by means of how that
code works, is the executable itself -- and that makes the loader abandon
any file look-ups and use the link map already present.
The two issues both boil down to the same bug -- no global scope present.
Patch offered: http://sourceware.org/ml/libc-alpha/2013-01/msg00635.html
[1] http://pubs.opengroup.org/onlinepubs/7908799/xsh/dlopen.html
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.