Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 558479

Summary: xmlsec1: bogus lt_dlopen() search path [rhel-5.9]
Product: Red Hat Enterprise Linux 5 Reporter: Tomas Hoger <thoger>
Component: xmlsec1Assignee: Daniel Veillard <veillard>
Status: CLOSED CURRENTRELEASE QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: medium Docs Contact:
Priority: medium    
Version: 5.9CC: ksrot, mvadkert, plyons, veillard
Target Milestone: rcKeywords: Security, SecurityTracking, ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: xmlsec1-1.2.9-8.3 Doc Type: Release Note
Doc Text:
Story Points: ---
Clone Of: 558476
: 833996 (view as bug list) Environment:
Last Closed: 2013-01-04 15:39:15 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:
Bug Depends On:    
Bug Blocks: 700467    

Description Tomas Hoger 2010-01-25 13:39:19 UTC
+++ This bug was initially created as a clone of Bug #558476 +++

Description of problem:
xmlsec1 uses an embedded copy of libtool's ltdl to lt_dlopen() xmlsec1 wrappers for various crypto libraries (openssl, nss, gnutls).  ltdl version bundled with xmlsec1 is, however, quite old and does not include following upstream commit:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=30ab30e06ad06aad77a478f3f6e51a5db5bfc2f5

Due to that, if xmlsec1 is built on the system with 'include ld.so.conf.d/*.conf' in /etc/ld.so.conf, it will add 'include' and 'ld.so.conf.d/*.conf' to library search path used by ltdl.  Those relative paths are searched after system lib directories (/lib /usr/lib) and hence are only tried when appropriate xmlsec1-<crypto> (or xmlsec1-<crypto>-devel, due to a bug #541599) is not installed.

Note: The above problem affects Fedora / RHEL builds of xmlsec1.  Local builds on system with kernel / kernel-xen packages installed may add additional relative patch to search path, if 'hwcap 0 nosegneg' is listed in one of /etc/ld.so.conf.d/* files (see bug #209930).  That was fixed by libtool upstream via:

http://git.savannah.gnu.org/cgit/libtool.git/commit/?id=b3251f4d7e86d0bd4901de62cd9bcd18ddd7965a

Version-Release number of selected component (if applicable):
xmlsec1-1.2.12-2.fc12

Steps to Reproduce:
Run:
strace -e trace=file /usr/bin/xmlsec1 --verify --crypto FOO /dev/null

Search output for lines as:
open("/lib64/libxmlsec1-FOO.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib64/libxmlsec1-FOO.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("include/libxmlsec1-FOO.so", O_RDONLY) = -1 ENOENT (No such file or directory)
open("ld.so.conf.d/*.conf/libxmlsec1-FOO.so", O_RDONLY) = -1 ENOENT (No such file or directory)

Comment 2 RHEL Program Management 2010-08-09 19:18:48 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.

Comment 5 Daniel Veillard 2011-04-22 06:40:04 UTC
Fixed in xmlsec1-1.2.9-8.3 build

Daniel