Bug 1370065 - curl injects non-threaded libldap into possibly threaded program expecting libldap_r instead
Summary: curl injects non-threaded libldap into possibly threaded program expecting li...
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: openldap
Version: 29
Hardware: All
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Matus Honek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1626077
TreeView+ depends on / blocked
 
Reported: 2016-08-25 08:41 UTC by Jan Engelhardt
Modified: 2018-09-06 14:14 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Feature: Make libldap library to be a symlink to libldap_r library. Reason: When an application uses libraries that use both libldap or libldap_r, the libraries sometimes happen to use a different function than expected. Result:
Clone Of:
: 1626077 (view as bug list)
Environment:
Last Closed:


Attachments (Terms of Use)
testcase (1.06 KB, application/x-xz)
2016-08-25 08:41 UTC, Jan Engelhardt
no flags Details

Description Jan Engelhardt 2016-08-25 08:41:49 UTC
Created attachment 1193914 [details]
testcase

Description of problem:
A given (threaded) program uses libldap_r. It now also wants to make use of libcurl. Because libcurl is linked to libldap (on RHEL 6, Fedora rawhide du jour, openSUSE 42.1, and presumably other distributions), the threaded program starts using the functions from unthreaded ldap and breaks in strange kinds of ways.

Version-Release number of selected component (if applicable):
libcurl-7.50.1-1.fc26.x86_64
libcurl-7.19.7-52.el6.x86_64

How reproducible:
1. git clone git://git.inai.de/ldapmix  OR pick attachment 1 [details]
2. yum install openldap-devel libcurl-devel libtool gcc
3. autoreconf -fi; configure; make; ./server

This is a sample program; it is non-threaded, but it shows the problem that both libldap can end up in the process image, and there is no way to control it, because libcurl "belongs to the distro" and is otherwise an opaque thing to other programs.

Actual results:
[root@v-rawhide ldapmix]# ./server 
ldap_initialize we used was 0x7f505149b420
7f504f0f2000-7f504f146000 r-xp 00000000 08:03 148717                     /usr/lib64/libldap_r-2.4.so.2.10.7
7f504f146000-7f504f346000 ---p 00054000 08:03 148717                     /usr/lib64/libldap_r-2.4.so.2.10.7
7f504f346000-7f504f349000 r--p 00054000 08:03 148717                     /usr/lib64/libldap_r-2.4.so.2.10.7
7f504f349000-7f504f34a000 rw-p 00057000 08:03 148717                     /usr/lib64/libldap_r-2.4.so.2.10.7
7f505148c000-7f50514da000 r-xp 00000000 08:03 148715                     /usr/lib64/libldap-2.4.so.2.10.7
7f50514da000-7f50516d9000 ---p 0004e000 08:03 148715                     /usr/lib64/libldap-2.4.so.2.10.7
7f50516d9000-7f50516dc000 r--p 0004d000 08:03 148715                     /usr/lib64/libldap-2.4.so.2.10.7
7f50516dc000-7f50516dd000 rw-p 00050000 08:03 148715                     /usr/lib64/libldap-2.4.so.2.10.7


Expected results:
ldap_initialize from libldap_r should have been used.


Additional info:
In a sense, this is an issue discussed previously at various levels:
- https://mail-index.netbsd.org/tech-userlevel/2013/05/22/msg007832.html (!)
- http://www.openldap.org/lists/openldap-technical/200801/msg00015.html

What's best to do?

* replace -lldap by -lldap_r in all distribution packages (in principle, the problem is not limited to curl)
* editing the openldap package and in %install, forcing that libldap-2.4.so.2 be exactly the same as libldap_r-2.4.so.2.
* adding symbol versioning to the libraries
* …

Comment 1 Kamil Dudka 2016-08-25 16:16:53 UTC
(In reply to Jan Engelhardt from comment #0)
> Additional info:
> In a sense, this is an issue discussed previously at various levels:
> - https://mail-index.netbsd.org/tech-userlevel/2013/05/22/msg007832.html (!)
> - http://www.openldap.org/lists/openldap-technical/200801/msg00015.html

As far as I understand, the above discussions just describe the problem.  Has there been any solution proposed or reviewed by openldap developers?

> What's best to do?
> 
> * replace -lldap by -lldap_r in all distribution packages (in principle, the
> problem is not limited to curl)

Is it really a solution?  Is not it going to break applications that link with -lcurl -lldap?

> * editing the openldap package and in %install, forcing that
> libldap-2.4.so.2 be exactly the same as libldap_r-2.4.so.2.
> * adding symbol versioning to the libraries
> * …

I believe it would be better to ask openldap developers first...

Comment 2 Jan Engelhardt 2016-08-28 19:04:15 UTC
>ask openldap developers first...

Done. http://www.openldap.org/lists/openldap-technical/201608/msg00093.html

>break applications that link with -lcurl -lldap?

Indeed. While conversing with upstream I found that Debian had implemented a solution which is workable and already deployed. Cf. http://www.openldap.org/lists/openldap-technical/201608/msg00094.html
Therefore reassigning to the Fedora openldap package.

Comment 3 Matus Honek 2016-08-31 13:26:09 UTC
FTR, here's upstream's (Howard Chu's) response:
> The OpenLDAP Project will not make such a change in the 2.x release family. 
> What distributions decide to do is up to them. There are still embedded 
> devices that use libldap, and have no thread support. We have no reason to 
> make it harder for them to build their own projects.

I think we should make the same move as Debian did, starting from rawhide on. That is, making libldap to be a symlink that points to libldap_r.

Comment 4 Fedora End Of Life 2017-02-28 10:09:21 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle.
Changing version to '26'.

Comment 5 Jan Kurik 2017-08-15 06:52:50 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 6 Jan Kurik 2018-08-14 11:08:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle.
Changing version to '29'.


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