Re: libltdl is inefficient and a security hazard

[Bob Friesenhahn]

It is pretty clear that lt_dlopenadvise() in ltdl.c intends to try 
doing a dlopen with ARCHIVE_EXT.  The documentation in the code says:

/* If FILENAME has an ARCHIVE_EXT or MODULE_EXT extension, try to
   open the FILENAME as passed.  Otherwise try appending ARCHIVE_EXT,
   and if a file is still not found try again with MODULE_EXT appended
   instead.  */

What is not clear is why the code is written this way.  Perhaps it is 
expected that dlopen attempts with a file with the extension specified 
by ARCHIVE_EXT will be filtered out by the subordinate loader. 
Perhaps the preopen loader would be triggered successfully by a file 
with extension ARCHIVE_EXT, and perhaps the intent is to use a static 
module if possible.  If so, there is no code which is trying to do any 
such filtering so these requests are getting passed to the filesystem. 
Since the requests always fail, every candidate directory gets tested, 
which is very slow.

      /* First try appending ARCHIVE_EXT.  */
      errors += try_dlopen (&handle, filename, archive_ext, advise);

      /* If we found FILENAME, stop searching -- whether we were able to
         load the file as a module or not.  If the file exists but loading
         failed, it is better to return an error message here than to
         report FILE_NOT_FOUND when the alternatives (foo.so etc) are not
         in the module search path.  */
      if (handle || ((errors > 0) && !file_not_found ()))
        return handle;

Anything which touches the filesystem is very expensive and to be 
avoided if at all possible if we want to stop people from deleting the 
.la files due to sucking the life out of their systems.

The conditions in the code can simply be reversed so that the shared 
library extension is tested first.  Does anyone know a reason for the 
current order?

Bob
--
Bob Friesenhahn
address@hidden, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/