[Pkg-openldap-devel] Bug#327585: Bug#327585: Bug#327585: reopening

[Steve Langasek]

On Sun, Feb 03, 2008 at 05:17:45PM -0800, Russ Allbery wrote:
> Stephen Gran <sgran at debian.org> writes:

> > reopen 327585
> > found 327585 2.3.35-1
> > thanks

> > This is in all likelihood not fixed (I am struggling with similar issues
> > in freeradius, and I can guarantee the same techniques are not working
> > there, and we both use the Debian ltdl).  See
> > https://bugs.launchpad.net/openldap/+bug/90812 for more reports of it
> > being broken.

> Well, I tested the Perl backend in slapd a while back and it worked for
> me, so I really do think this bug is closed.  That's why I closed it.

Did you test the perl backend using any XS modules?

The Debian OpenLDAP packages are linked against the system libltdl, which
opens all objects with RLTD_LOCAL instead of RTLD_GLOBAL.  RTLD_GLOBAL is
what upstream libltdl uses, but it's not a sane behavior for a
general-purpose system library because it's completely unscalable and has
resulted in symbol clobbering bugs in the past; so the Debian package is
patched to use RLTD_LOCAL, which in turn is not usable for the case of
multiple levels of plugins where the plugins at the bottom level reference
symbols that they expect to be provided by the caller.

Since the perl package in Debian is not linked against libperl, perl
extensions also cannot be linked against libperl since this would cause two
copies of the perl XS symbols to be loaded.  So perl modules have dangling
symbol references that are expected to be resolved by whatever dlopen()s
them, but if the perl interpreter itself is loaded via dlopen(RTLD_LOCAL),
the perl symbols are not visible to the very perl extensions that it's
loading, regardless of what flags the perl interpreter itself uses when
calling dlopen().

Stephen and I were just discussing this extensively this morning in
connection with freeradius, which has the same problem in Debian for
rlm_perl; I'm pretty sure this analysis is correct, but I'm open to the
possibility that it works by some means I haven't thought of so am
interested to hear of any test cases you have for this.

BTW, a similar bug was reported recently (... in the past 3 months or so;
and possibly only via the mailing list) on the OpenLDAP package because
back_meta references symbols from back_ldap but doesn't link against it, so
back_meta in Debian can never see those symbols even if back_ldap is loaded
first.  I have a possible fix for this (which btw is detected by upstream's
'make test'), but have been reluctant to implement it so far because it's an
ugly thing involving making symlinks to back_ldap to keep libtool happy.

Ultimately, I think it was a poor decision for the libltdl authors to create
an interface that doesn't support specifying crucial flags like RTLD_GLOBAL
and RTLD_LOCAL when opening objects, as this has left us with use cases
which have mutually exclusive requirements.  Perhaps it's time to try to
persuade libltdl upstream to add a fixed interface.

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