This service will be undergoing maintenance at 20:00 UTC, 2017-04-03. It is expected to last about 30 minutes
Bug 209930 - libtool-ltdl searches in relative paths
libtool-ltdl searches in relative paths
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: libtool (Show other bugs)
5
All Linux
urgent Severity urgent
: ---
: ---
Assigned To: Karsten Hopp
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-08 09:17 EDT by Enrico Scholz
Modified: 2010-01-25 08:31 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-23 12:12:28 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Enrico Scholz 2006-10-08 09:17:47 EDT
Description of problem:

libltdl seems to be built in some way which results into a
library-searchpath containing relative paths:

E.g.

--- victim.c ----
#include <ltdl.h>

int main() {
        lt_dlinit();
        lt_dlhandle     h = lt_dlopenext("foo");
        void            (*f)(void) = lt_dlsym(h, "foo");
        (*f)();
}
----

--- foo.c ---
void foo()
{
        write(1, "got you...\n", 11);
}
----

| $ gcc -g3 -O0 victim.c -o bin/victim -lltdl
| $ libtool --mode=compile gcc -g3 -O0 -c foo.c
| $ libtool --mode=link gcc -rpath `pwd`/bin/nosegneg -module -avoid-version  -o foo.la foo.lo
| $ libtool --mode=install install foo.la `pwd`/bin/hwcap/foo.la
| 
| $ cd bin
| $ strace ./victim
| open("/lib/foo.la", O_RDONLY)           = -1 ENOENT (No such file or directory)
| open("/usr/lib/foo.la", O_RDONLY)       = -1 ENOENT (No such file or directory)
| open("hwcap/foo.la", O_RDONLY)          = -1 ENOENT (No such file or directory)
| open("0/foo.la", O_RDONLY)              = -1 ENOENT (No such file or directory)
| open("nosegneg/foo.la", O_RDONLY)       = 3
| ...
| write(1, "got you...\n", 11got you...
| ...


This relative paths are in libltdl.so:

| $ strings /usr/lib/libltdl.so | grep hwc
| /lib:/usr/lib:hwcap:0:nosegneg:/usr/lib/mysql:/usr/lib/mysql:/usr/lib/mysql:/usr/lib/qt-3.3/lib
| /lib:/usr/lib:hwcap:0:nosegneg:/usr/lib/mysql:/usr/lib/mysql:/usr/lib/mysql:/usr/lib/qt-3.3/lib


The 'mysql' and 'qt' paths do not seem to be ok either.


Version-Release number of selected component (if applicable):

libtool-ltdl-1.5.22-2.3
Comment 1 Karsten Hopp 2006-11-06 08:57:05 EST
partly caused by /etc/ld.so.conf.d/kernelcap-* from the kernel-xen package which
puts some varaiables instead of directories into the configfile.
I have a patch to ignore everything which doesn't looks like an absolute path in
/etc/ld.so.conf.d/*, but I still have 'open("foo.la", O_RDONLY)' which I'm
looking for right now.

Comment 2 Karsten Hopp 2006-11-06 10:55:14 EST
Can you try out http://people.redhat.com/karsten/libtool-1.5.22-2.7.src.rpm ,
please ? It should ignore the entries in /etc/ld.so.conf.d/kernelcap-* and
shouldn't look in the current working directory for .la files.
Please try to start some programs linked with libltdl and post any findings here.
Thanks !
Comment 3 Lubomir Kundrak 2006-11-20 15:13:10 EST
Would't it be better if sys_search_path[] was determined system's actual
configuration at runtime? From my point of view hardcoding it and depending on
build host setup makes no sense for pre-compiled binary based system. But I am
unaware of a possible performance penalty, would there be any?
Comment 4 Karsten Hopp 2007-01-23 12:12:28 EST
fixed in the latest rawhide package
Comment 5 Tomas Hoger 2010-01-25 08:31:41 EST
Upstream commit, noted for posterity:
http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b3251f4d7e86d0bd4901de62cd9bcd18ddd7965a

Note You need to log in before you can comment on or make changes to this bug.