[Pkg-openldap-devel] libldap_r

[Russ Allbery]

Steve Langasek <vorlon at debian.org> writes:
> On Thu, Dec 20, 2007 at 10:43:48PM -0800, Russ Allbery wrote:

>> I'd really like to sort out the libldap_r thing, since what we're doing
>> right now is one of those sorts of things that I'm sure upstream would
>> say that we shouldn't do and we're just creating problems by doing.

>> So, could you check this for accuracy so that I can correctly represent
>> the problem that we're trying to solve to upstream and get their take
>> on how we *should* solve it?

>>     Currently, OpenLDAP installs both a libldap and a libldap_r
>>     library, the latter used by slapd.  The symbols provided by the two
>>     libraries overlap.  This creates a problem when both libraries are
>>     loaded into the same process space, such as on a system that uses
>>     an LDAP NSS module and hence loads libldap into slapd's process
>>     space when slapd makes a getpwnam() call (to implement the -u flag,
>>     for example).

> Well, since nss_ldap gets used by all applications, it needs to be
> linked against the thread-safe version of libldap, even though most apps
> are going to be looking for plain -lldap.  So the scope of this is far
> beyond slapd; indeed, slapd is one app that should not be affected by
> this particular issue.

Let me try to restate this a little and try to put my finger on the
problem that I'd express to upstream.

libldap_r is the thread-safe version and libldap is not thread-safe, so
threaded applications have to link with libldap_r.  However, libldap and
libldap_r both contain the same symbols and don't use symbol versioning.
So if both are loaded into the same process space at the same time, it's
undefined which library is called, which can cause all sorts of problems.

Therefore, for modules like nss-ldap that are loaded into the process
space of almost every system process, there is no good option for which
library to link against in the presence of both libraries:  Linking with
libldap because nss-ldap isn't threaded means that threaded applications
that link with libldap_r may resolve symbols to the wrong library and may
cause problems if NSS functions are called by threaded applications, and
linking with libldap_r to be safe for threaded applications but will cause
problems for any application linked with libldap.

Does that sound right?

What if upstream suggests playing with linker flags and/or dlopen flags to
limit the namespace when loading modules like nss-ldap?  Does that even
work?

> The right answer is to get the server stuff out of libldap so that we
> can (on GNU systems) get a thread-safe libldap that doesn't have to link
> to libpthread.  Let's hope upstream sees it that way... :)

The idea being that if libldap uses only a select set of pthread
interfaces, it won't need to be linked with the pthread libraries on GNU
systems but will use the proper threading primitives if libpthread is
already loaded?

How do we tell upstream which interfaces they could use under this model?
Do we know for sure that all the other interfaces currently in use are
only used by slapd?

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>