|
From: | Peter O'Gorman |
Subject: | Re: libltdl is inefficient and a security hazard |
Date: | Mon, 26 Oct 2009 11:46:49 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-2.7.b4.fc11 Thunderbird/3.0b4 |
On 10/25/2009 09:04 PM, Bob Friesenhahn wrote:
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?
It's been a while since I've looked at libltdl, so the following may not be correct.
It tries the .a first for the preopen loaders, as you guessed, but, of course, the other loaders don't know that and look for it anyway, failing, and flailing along, until the preopen loader has a chance, and (in most cases) fails.
Changing the search order would "break" things that use the preopen loader if there is a shared module also available. I don't think such a change is acceptable.
I would suggest that libltdl explicitly limit the searching for the .a archive to the preopen loader(s) to stop the filesystem getting involved there.
If lt_dlopen is passed an absolute path, it shouldn't really be searching at all. I'd call that a different bug though.
Feel free to delve in and propose patches. Peter -- Peter O'Gorman http://pogma.com
[Prev in Thread] | Current Thread | [Next in Thread] |