Bug 209930
| Summary: | libtool-ltdl searches in relative paths | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Enrico Scholz <rh-bugzilla> |
| Component: | libtool | Assignee: | Karsten Hopp <karsten> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | urgent | Docs Contact: | |
| Priority: | urgent | ||
| Version: | 5 | CC: | k.georgiou, lkundrak, wtogami |
| Target Milestone: | --- | Keywords: | Security |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2007-01-23 17:12:28 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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.
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 ! 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? fixed in the latest rawhide package Upstream commit, noted for posterity: http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b3251f4d7e86d0bd4901de62cd9bcd18ddd7965a |
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