[Date Prev][Date Next]
Re: liblber makefile regresses other libraries (ITS#2798)
On Mon, 27 Oct 2003 firstname.lastname@example.org wrote:
> Date: Mon, 27 Oct 2003 20:41:11 GMT
> From: email@example.com
> To: openldap-its@OpenLDAP.org
> Subject: liblber makefile regresses other libraries (ITS#2798)
> Full_Name: Joseph S D Yao
> Version: 2.1.22
> OS: Linux - Red Hat 8.0 w/ patches and Bastille
> URL: ftp://ftp.openldap.org/incoming/Joseph-Yao-031027-02.txt
> Submission from: (NULL) (184.108.40.206)
> This is a security issue, as it regresses previously installed libraries
> with fixes back to the less secure forms.
> Starting with Red Hat Linux 8.0, after adding patches and Bastille
> Linux, I installed OpenSSL 0.9.7c, OpenLDAP 2.1.22, and Sendmail
> 8.12.10. When I got to 'sendmail', it declared that some of the
> libraries in the previous packages were inconsistent.
> It turns out that, while installing OpenLDAP, the liblber Makefile calls
> 'libtool', which calls 'ldconfig'. The new OpenLDAP library is NOT
> entered into the library configuration by 'ldconfig'. But the symbolic
> links in /usr/lib to libssl.so.0.9.7 and libcrypto.so.0.9.7 have been
> removed, and replaced by symbolic links to the original 0.9.5a files.
That is an OpenSSL issue. Each shared library has a SONAME which you
can display using "objdump -p <file>". When running ldconfig it scans
through all shared libraries in /lib and /usr/lib and looks up the
SONAME; the SONAME is then used as the name of a symbolic link referred
to the shared library. The reason for this is that the programs which
needs to load shared libraries do so by the SONAME. This also implies
that you cannot normaly have two shared libraries on the system with
the same SONAME. In theory the shared libraries with the same SONAME
should be binary compatible, but that is all too often not the case,
and libraries like OpenSSL and BerkeleyDB has been known to break binary
compatibility on minor version change.
There is nothing that can be done in openldap to prevent this.