[Pkg-openldap-devel] libldap_r

[Steve Langasek]

On Sat, Jan 05, 2008 at 02:17:32PM -0800, Russ Allbery wrote:
> Steve Langasek <vorlon at debian.org> writes:
> > On Thu, Dec 20, 2007 at 10:43:48PM -0800, Russ Allbery wrote:

> >>     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?

Yes, right on the nose, with the minor additional twist that if nss-ldap is
linked against libldap, any threaded app may get undefined behavior from nss
calls.

> 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?

Well, it's certainly not scalable, and is contingent on the options passed
to dlopen() (by glibc when opening nss modules, or by any other applicable
interfaces, such as, oh, any interpreted language with LDAP bindings).  But
even then I'm not sure there's a 100% reliable solution, I think it would
also depend on certain cases where the behavior is undefined.

> > 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?

Yep.

> 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?

 nm -D /lib/libc.so.6 |grep pthread

gives a list of just under 40 symbols that can be safely used on GNU systems
without having to link to libpthread.

I don't /know/ that all the other interfaces are only used by slapd, but if
they are used via public library calls that would itself be bizarre and
probably a bug since a library shouldn't, e.g., be calling pthread_join(),
pthread_kill(), or pthread_attr_setstacksize().

Fixing this is going to be a bit of work regardless since currently, all the
thread handling in openldap is encapsulated in the library and this split
would require also splitting the thread lib wrapper code between server and
lib components.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org