Bug 46884 - Call to apu_dso_load Fails In apr_ldap_stub.c On Older Versions Of HP-UX
Summary: Call to apu_dso_load Fails In apr_ldap_stub.c On Older Versions Of HP-UX
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ldap (show other bugs)
Version: 2.2.11
Hardware: HP HP-UX
: P3 minor (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate
Depends on:
Blocks:
 
Reported: 2009-03-20 12:46 UTC by Patrick Heckenlively
Modified: 2018-11-07 21:10 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Heckenlively 2009-03-20 12:46:18 UTC
We noticed the following in the error log on one of our Apache 2.2.11 instances:

sasl.c:74: failed assertion `ld != NULL'
[Mon Mar 02 09:25:17 2009] [notice] child pid 25633 exit signal Abort (6)

We quickly determined that the file sasl.c referenced above is part of the OpenLDAP code base.

After exhaustive research that included running Apache inside gdb, I believe that I have tracked down the cause in what appears to be a minor bug in apr_ldap_stub.c.  Observe the following code snippet starting in line 48 of apr_ldap_stub.c:

#if defined(NETWARE)
    modname = "aprldap.nlm";
#elif defined(WIN32)
    modname = "apr_ldap-" APU_STRINGIFY(APU_MAJOR_VERSION) ".dll";
#else
    modname = "apr_ldap-" APU_STRINGIFY(APU_MAJOR_VERSION) ".so";
#endif
    rv = apu_dso_load(&symbol, modname, "apr__ldap_fns", pool);
    if (rv == APR_SUCCESS) {
        lfn = symbol;
    }

Because we are on a UNIX platform, the variable modname acquires the value "apr_ldap-1.so".  However, because we are on PA-Risc based HP-UX 11.11, the Apache build process creates this file with the name "apr_ldap-1.sl".  This causes the call to apu_dso_load to fail.  This in turn causes Apache to call OpenLDAP libraries with improperly initialized parameter(s), which is why we get the failed assertion in sasl.c in the OpenLDAP code base.

Thankfully, the workaround is trivial.  In SERVERROOT/lib/apr-util-1, I
symlinked apr_ldap-1.so to apr_ldap-1.sl, and LDAP authentication works
without the error described above.

A back trace of how execution gets to this point follows:

(gdb) bt
#0  load_ldap (pool=0x40164020) at ldap/apr_ldap_stub.c:53
#1  0x7ade9d30 in apr_ldap_init (pool=0x40164020, ldap=0x40086cc0, 
    hostname=0x40086d68 "REDACTEDHOSTNAME", portno=636, secure=0, 
    result_err=0x7ab47854) at ldap/apr_ldap_stub.c:82
#2  0xc90b4 in uldap_connection_init (r=0x40164060, ldc=0x40086cc0)
    at util_ldap.c:228
#3  0xc93e8 in uldap_connection_open (r=0x40164060, ldc=0x40086cc0)
    at util_ldap.c:353
#4  0xcaa6c in uldap_cache_checkuserid (r=0x40164060, ldc=0x40086cc0, 
    url=0x400ccfd8 "REDACTEDURL", basedn=0x400cd040 "REDACTEDBASEDN", scope=2, 
    attrs=0x400cd058, 
    filter=0x7ab455d0 "REDACTEDFILTER", 
    bindpw=0x40165560 "REDACTEDBINDPW", binddn=0x7ab475e0, 
    retvals=0x7ab455cc) at util_ldap.c:954
#5  0xb85d8 in authn_ldap_check_password (r=0x40164060, 
    user=0x40165578 "REDACTEDUSER", password=0x40165560 "REDACTEDPASSWORD")
    at mod_authnz_ldap.c:399
#6  0xbbe40 in authenticate_basic_user (r=0x40164060) at mod_auth_basic.c:230
#7  0xa7a50 in ap_run_check_user_id (r=0x40164060) at request.c:71
#8  0xa8c1c in ap_process_request_internal (r=0x40164060) at request.c:190
#9  0x2064e8 in ap_process_request (r=0x40164060) at http_request.c:280
#10 0x20185c in ap_process_http_connection (c=0x40142538) at http_core.c:190
#11 0x9c768 in ap_run_process_connection (c=0x40142538) at connection.c:43
#12 0x9ce24 in ap_process_connection (c=0x40142538, csd=0x40142448)
    at connection.c:178
#13 0x236dbc in process_socket (p=0x40142408, sock=0x40142448, my_child_num=0, 
    my_thread_num=0, bucket_alloc=0x40162010) at worker.c:544
#14 0x237aa4 in worker_thread (thd=0x400d2c50, dummy=0x40141ff8)
    at worker.c:894
#15 0x7ae81f20 in dummy_worker (opaque=0x400d2c50)
    at threadproc/unix/thread.c:142
#16 0x7aecd290 in __pthread_body () from /usr/lib/libpthread.1
(gdb)
Comment 1 William A. Rowe Jr. 2018-11-07 21:10:00 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.