[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libltdl is inefficient and a security hazard
From: |
Bob Friesenhahn |
Subject: |
Re: libltdl is inefficient and a security hazard |
Date: |
Sun, 25 Oct 2009 21:04:46 -0500 (CDT) |
User-agent: |
Alpine 2.01 (GSO 1266 2009-07-14) |
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/