libltdl is inefficient and a security hazard

[Bob Friesenhahn]

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/