php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #45886 ldap_bind fails with out of memory
Submitted: 2008-08-21 20:14 UTC Modified: 2008-09-05 16:04 UTC
From: rocko823 at gmail dot com Assigned:
Status: Closed Package: LDAP related
PHP Version: 5.2.6 OS: Solaris 10 SPARC
Private report: No CVE-ID: None
 [2008-08-21 20:14 UTC] rocko823 at gmail dot com
Description:
------------
PHP 5.2.6 with Apache 2.2.9 with this configure: './configure' '--with-apxs2=/web/apache/bin/apxs' '--with-mysql=/local/mysql32' '--with-gd' '--with-jpeg-dir=/usr/local/' '--with-zlib' '--with-oci8=instantclient,/local/instantclient_10_2' '--with-mcrypt' '--with-ldap' '--with-ldap-sasl' '--with-openssl=/usr/local/ssl'

with openldap 2.3.39

When ldap_connect then ldap_bind is run it fails with ldap error "Out of memory" only when run under Apache 2 module, with the command line client it runs correctly.

Reproduce code:
---------------
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
$ds=ldap_connect("ldap://server");

if ($ds) {
    $r=@ldap_bind($ds, "user", "password");
    if ($r) {
       echo "success";
    } else {
       echo "fail:" . ldap_error($ds);
    }
}


Expected result:
----------------
PHP connects and binds to the LDAP server and returns success

Actual result:
--------------
PHP returns ldap error "Out of memory".  PHP doesn't even try to connect to the LDAP server.  In the apache error logs I see these ldap debugging messages:
ldap_create
ldap_url_parse_ext(ldap://server)
ldap_bind_s
ldap_simple_bind_s
ldap_sasl_bind_s
ldap_sasl_bind

and it stops there where when run with the command line and a success there are many more lines

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2008-08-21 20:53 UTC] jani@php.net
Try disabling oci8. And check also that Apache is linked with same Openssl libs as you're linking PHP with.
 [2008-08-22 16:23 UTC] rocko823 at gmail dot com
Both apache and PHP are linked against a compiled version of openssl 0.9.8h

Unfortunately I cannot disable OCI8 as the projects on this server require Oracle database access.  I have attempted to recreate this problem on a test Intel machine running Solaris 10 but the problem does not occur.  If I can get my hands on a test Sparc Solaris 10 Box I can try disabling OCI8 to see if that has any effect.  However I really need both modules running.  Why would OCI8 have any effect on the LDAP module?
 [2008-08-22 17:05 UTC] jani@php.net
Because some oracle libs contain their own implementation of ldap functions and conflict with openldap ones. And IIRC, Solaris also has it's own ldap stuff (sometimes) so in worst case you have 3 different set of libs around and the mess is ready. 

You could try compiling PHP ldap using the oracle libs:

--with-ldap=/local/instantclient_10_2/

I'm not sure if this instantclient thing has the ldap stuff, but I guess it's worth trying..
 [2008-08-27 20:45 UTC] rocko823 at gmail dot com
I found the problem.

This apparently occurs when the Apache LDAP modules (mod_authnz_ldap, and mod_ldap) are not loaded.  I added these to my LoadModule section in httpd.conf and now ldap_connect and ldap_bind work perfectly.  I'm not really sure why this would be as I've had previous set ups and not used the Apache LDAP module.
 [2008-08-27 21:10 UTC] jani@php.net
Check the libphp5.so what it's linked with. (ldd libphp5.so)
 [2008-08-27 21:25 UTC] rocko823 at gmail dot com
output from ldd libphp5.so

        librt.so.1 =>    /usr/lib/librt.so.1
        libmysqlclient.so.15 =>  /local/mysql32/lib/libmysqlclient.so.15
        libmcrypt.so.4 =>        /local/lib/libmcrypt.so.4
        libltdl.so.3 =>  /local/lib/libltdl.so.3
        libldap-2.3.so.0 =>      /local/lib/libldap-2.3.so.0
        libpng12.so.0 =>         /usr/lib/libpng12.so.0
        libssl.so.0.9.8 =>       /usr/local/ssl/lib/libssl.so.0.9.8
        libcrypto.so.0.9.8 =>    /usr/local/ssl/lib/libcrypto.so.0.9.8
        libresolv.so.2 =>        /usr/lib/libresolv.so.2
        libm.so.2 =>     /usr/lib/libm.so.2
        libnsl.so.1 =>   /usr/lib/libnsl.so.1
        libsocket.so.1 =>        /usr/lib/libsocket.so.1
        libxml2.so.2 =>  /usr/lib/libxml2.so.2
        libclntsh.so.10.1 =>     /local/instantclient_10_2/libclntsh.so.10.1
        libc.so.1 =>     /usr/lib/libc.so.1
        libgcc_s.so.1 =>         /usr/sfw/lib/libgcc_s.so.1
        libaio.so.1 =>   /usr/lib/libaio.so.1
        libmd.so.1 =>    /usr/lib/libmd.so.1
        libpthread.so.1 =>       /usr/lib/libpthread.so.1
        libthread.so.1 =>        /usr/lib/libthread.so.1
        libgen.so.1 =>   /usr/lib/libgen.so.1
        libm.so.1 =>     /usr/lib/libm.so.1
        libdl.so.1 =>    /usr/lib/libdl.so.1
        liblber-2.3.so.0 =>      /local/lib/liblber-2.3.so.0
        libsasl2.so.2 =>         /local/lib/libsasl2.so.2
        libucb.so.1 =>   /usr/ucblib/libucb.so.1
        libelf.so.1 =>   /usr/lib/libelf.so.1
        libz.so.1 =>     /usr/lib/libz.so.1
        libmp.so.2 =>    /usr/lib/libmp.so.2
        libscf.so.1 =>   /usr/lib/libscf.so.1
        libnnz10.so =>   /local/lib/libnnz10.so
        libkstat.so.1 =>         /usr/lib/libkstat.so.1
        libsched.so.1 =>         /usr/lib/libsched.so.1
        libdoor.so.1 =>  /usr/lib/libdoor.so.1
        libuutil.so.1 =>         /usr/lib/libuutil.so.1
        /platform/SUNW,Sun-Fire-480R/lib/libc_psr.so.1
        /platform/SUNW,Sun-Fire-480R/lib/libmd_psr.so.1

I checked the apache ldap modules and they are linking against the same versions of the ldap libs as reported above for libphp5.so
 [2008-08-28 21:27 UTC] jani@php.net
Could you please try with a PHP compiled without oracle just that we can rule out that from this?
 [2008-09-04 16:01 UTC] rocko823 at gmail dot com
sorry for the delay, I was on extended holiday vacation.  I have confirmed that this problem does not occur when the Oracle oci8 is not compiled into PHP and all other factors stay the same.
 [2008-09-04 20:51 UTC] jani@php.net
Ok, so it's most likely the old issue with Oracle libs containing their own ldap API which conflicts with openldap. In this case, you should configure PHP to use the oracle libs for ldap too. ie. pass --with-ldap the proper path to the oracle libs.
 [2008-09-05 16:04 UTC] rocko823 at gmail dot com
I'll look into how to do that, but the Instant Client doesn't deliver any LDAP specific include files like ldap.h which PHP needs.

I will close this bug because it really isn't PHP specific, it is more how the operating system loads up the libraries when running in Apache and the fact that the LDAP parts of the Oracle libs are stomping on openldap.  I suspect having Apache load in the LDAP libraries due to its own LDAP modules is forcing the LDAP functions to register with openldap instead of the oracle libs.  Probably the best solution to this is using LD_PRELOAD with Apache on the openldap libraries for them to get loaded first before the Oracle lib.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 05 05:01:29 2024 UTC