[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
libltdl is inefficient and a security hazard
From: |
Bob Friesenhahn |
Subject: |
libltdl is inefficient and a security hazard |
Date: |
Sun, 25 Oct 2009 16:14:05 -0500 (CDT) |
User-agent: |
Alpine 2.01 (GSO 1266 2009-07-14) |
I posted a bug report with the same subject several days ago to the
bug-libtool list (with data) but no discussion ensued so I will open
the issue for broader discussion here.
I was observing very poor execution performance of the modules-based
build of my application under Solaris. It used to execute quite well
under Solaris (better than a static build) when using loadable
modules. Now using any loadable modules via libltdl makes the minimum
program execution time 4X slower, and this is when loading only two
modules. Looking at system calls showed massive amounts of 'stat'
calls and reloading the same shared libraries many times.
While there are several issues to fix, it seems that libltdl has a bug
with both performance and security implications. When a libtool
module is opened via its ".la" file, I expect that the .la file will
be parsed. The file name given by 'dlname' will be appended to the
path name given by 'libdir'. This full path should then be given to
the system's dlopen(). Then I expect that the path specified by
lt_dlsetsearchpath() (LTDL_LIBRARY_PATH) should be used, while always
passing a fully qualified path to dlopen(). If these explicit loads
fail, then an unqualified path can be used to load the module and the
system can have its way with it.
Instead what I see happening is for a module called "module.la", first
there is an attempt to dlopen "module.a" and then "module.so" and the
system's shared library search path is used. Lastly, there is
(finally) a request to load module.so via the correct full path.
Since libltdl also attempts to explicitly load all of the dependency
libraries, I see the same wonky things done for all of the libraries
that the module depends on (e.g. libc.so). This adds many hundreds of
additional slow system calls to program initialization.
This is what the libtool documentation says regarding search paths:
"
If libltdl cannot find the library and the file name filename does not
have a directory component it will additionally look in the following
search paths for the module (in the following order):
1. user-defined search path: This search path can be changed by the
program using the functions lt_dlsetsearchpath, lt_dladdsearchdir and
lt_dlinsertsearchdir.
2. libltdl's search path: This search path is the value of the
environment variable LTDL_LIBRARY_PATH.
3. system library search path: The system dependent library search
path (e.g. on Linux it is LD_LIBRARY_PATH).
"
I tried using lt_dlsetsearchpath() to explicitly set the search path
to the directory where the module is located, but it had no influence
on the searches performed.
Bb
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
- libltdl is inefficient and a security hazard,
Bob Friesenhahn <=