Hi all, I just upgraded my 2.0.44 apache to 2.0.45 due to the last security warning. Unfortunatly, everytime I'm trying to access to a page protected by LDAP, the child crash : The error log says [Mon Apr 07 12:08:30 2003] [notice] child pid 23255 exit signal Bus error (10) My .htaccess is : AuthName "Protected" AuthType Basic AuthLDAPURL "ldap://ldapmain.mydomain.com ldapsecond.mydomain.com/ou=people,dc=mycompany,dc=com?uid?sub" require valid-user It seems it fails only when the authentification succeed (because w/ a wrong information, the authentification is reasked and the "access denied page" is displayed w/o problem). Same behaviour on both HP-UX 10.20 and 11 :-( Compiled using : ./configure --with-mpm=prefork -with-ldap --enable-ldap --enab le-auth-ldap --enable-info --enable-cgi --enable-expires --enable-so I have reinstalled 2.0.44 ... Bye Laurent
I have almost the same issue on Win32 -- at least when using Microsoft's LDAP (which is the default). The difference: I get a crash on failed authentication challenges too...
I've the same problem on Solaris. 2.0.44 and 2.0.43 seem ok, but if you look at http://servername/ldap-status on these builds it says ldap cache is disabled. Using OpenLdap libraries 2.1.8 originally, upgraded to 2.1.17, gives no change. 2.0.45 core dumps with Bus Error or Seg Fault when asking for a page (seems to do it every request) I've tested on Suse linux and it segfaults far less frequently, <10 times for 5000 hits. I've set up an LDAP server with 5000 dummy users and a script to use wget to ask for an authenticated page using different users. Configure options were ./configure --prefix=/opt/apache/httpd/2.0.44 --with-ssl=/opt/SSL/default --enable-so --enable-ssl --enable-auth-ldap --with-ldap --enable-ldap --enable-proxy --sysconfdir=/etc/apache2/conf --with-ldap-include=/opt/ldap/2.1. 8/include --with-ldap-lib=/opt/ldap/2.1.8/lib --enable-rewrite Though I've removed everything but the ldap flags and still get the same problem. Tried removing the ldap module and using the mod_auth_ldap from www. muquit.com - works fine, but I don't want to have to get my users to change all their access files :)
Hmmm... My problem on Windows went away when I installed and used the latest MSVC++ Service Pack and the latest Microsoft Platform SDK. I had the LDAP modules working fine on Solaris at 2.0.43, but have not tried them since (as the motivation to move to Apache 2 is not as great on UNIX). For those trying 2.0.45 on HP you may be interested to note that HP now provides a 2.0.45 build for their platform with an LDAP module, though I'm not sure which one...
Hello, > For those trying 2.0.45 on HP you may be interested to note that HP now provides > a 2.0.45 build for their platform with an LDAP module, though I'm not sure which one... I only use source tarball because I use several architectures (Sparc64/Solaris, Sparc/NetBSD, HP-UX) and don't want to have many different customised version of apache flying around. Anyway, I will check if HP has made some modification about this problem ... I hope, if they found something, they have warn apache team. Bye Laurent
I have since learned that HP's 2.0.45 still contains their own port of auth_ldap to Apache 2.0 from 1.3, unfortunately. I'm guessing they'll jump to the normal Apache modules one of these days...
I successfully installed Apache 2.0.45 with mod_auth_ldap and mod_ldap using the openldap 2.1.17 SDK and openSSL. I created a test directory with the following .htaccess file: AuthName "Test" AuthType Basic AuthLDAPURL "ldap://ldap.rit.edu:389/o=University Name, st=New York, c=US?uid" require valid-user When trying to access the directory I get prompted for username & password (as I should) but then I get a page cannot be displayed error (I know there is no problem with the page) no matter what i type in. I checked the Apache error log and this is what I see: [Mon Apr 21 12:45:17 2003] [notice] child pid 22179 exit signal Bus error (10) [Mon Apr 21 12:45:17 2003] [notice] child pid 22166 exit signal Bus error (10) [Mon Apr 21 12:51:12 2003] [notice] child pid 22182 exit signal Bus error (10) [Mon Apr 21 12:55:42 2003] [notice] child pid 22169 exit signal Bus error (10) [Mon Apr 21 12:55:42 2003] [notice] child pid 22180 exit signal Bus error (10) [Mon Apr 21 12:56:56 2003] [notice] child pid 22224 exit signal Bus error (10) [Mon Apr 21 12:56:56 2003] [notice] child pid 22223 exit signal Bus error (10) Thank you very much, Damian Marinaccio Rochester Institute of Technology RIT Library 585-475-7741 dxmwml@rit.edu
*** Bug 19820 has been marked as a duplicate of this bug. ***
*** Bug 19993 has been marked as a duplicate of this bug. ***
Created attachment 6512 [details] Termporary work-around
I have tried the suggestion for the workaround, but it only work for the first connection, subsequent requests returned a failed id. I am using apache 2.0.46, netscape ldap sdk, on solaris.
I have the bug on apache to 2.0.46 on win2k (standard binary distribution) while binding to an AD on a win2k server. The error log contains : [Fri Jun 20 10:49:02 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. This error occurs when I first to access a protected page. The only workaround was to use the mod_auth_ldap from www.muquit.com. It works works but I'd like to use the standard one, not using IPlanet libraries!
I forgot to say that the bug happens with 2.0.44 too.
It doesn't seem like the developers who made all those changes to auth_ldap for version 2.0.45 tested it very well. Where are they now? 2.0.46 is already out and doesn't include a fix. While I'm appreciative of the workaround. Having an authentication occur everytime a protected resource is accessed without caching is pretty unacceptable. So is having to run an old version of the HTTP server that has security vulnerabilities. IMHO, if the developers aren't going to come up with a fix for version 2.0.47, they should roll the auth_ldap code back to 2.0.44 (which worked just fine).
I believe the error is in the shared memory handling. After a lot of scaffolding, I found it was dying at line 396 of util_ldap_cache_mgr.c, in util_ald_cache_insert(), when node->add_time is set to the current time. On the assumption this indicated some sort of memory allocation problem when creating node, I then had a look at util_ald_alloc(). If the call to apr_rmm_addr_get() is replaced with a simple calloc(), the problem goes away.
Created attachment 7099 [details] This patch correct ldap cache shm which is broken in apache 2.0
Created attachment 7100 [details] This patch correct ldap cache shm which is broken in apache 2.0
I have just posted a patch i made one month ago to fix problems in ldap cache and shm. This code has been ported from apache 1.3 and was broken when using SHM. I tested the patch and it's working with worker MPM, i sent it on dev@httpd, but didn't get answer at this time. feedback are welcome Matthieu Sorry if i posted twice, i am new with bugzilla
The patch provided by Matthieu Estrade partially worked for me. I applied the patch to a clean 2.0.47 tree, and now I properly get a "LDAP: using file: /var/run/apache2/mod_ldap_cache for shm cache" message in the logfile (after setting the LDAPShmCacheFile option). I still get the "ldap cache init: Error 0" message though (even though the configured shm file is correctly created), but now the /ldap-status page correctly updates with cache information about the LDAP entries that have been attempted (stayed empty before). As mentioned in early comments, I also get the "exit signal Bus error (10)", which has not changed after patching of 2.0.47 (also have same problem with 2.0.45).
Commenting out the LDAP cache directives from the Apache config now allows me to successfully authenticate against my OpenLDAP 2.0.27 server, but no caching is happening. As my load is light, I can live with this :) In my previous 2.0.44 install, I was not using the LDAP cache directives, so I cannot comment as to whether they used to work or not. I had enabled them for my 2.0.47 install attempting to work around above mentioned bus errors. Note, the provided patch was required before my original config that did not include the LDAP cache directives worked successfully. For my case (no caching), the patch now works beautifully.
I have tryed to enable caching on my 2.0.44 environment. I have added following lines in my httpd.conf (as explained in mod_ldap documentation): #LDAP LDAPSharedCacheSize 200000 LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 <Location /ldap-status> SetHandler ldap-status Order deny,allow Deny from all Allow from mydomain.com AuthName "Protected" AuthType Basic AuthLDAPEnabled on AuthLDAPURL "ldap://ldapmain.mydomain.com ldapsecond.mydomain.com/ou=people,dc=mycompany,dc=com?uid?sub" AuthLDAPAuthoritative on require user "webmaster" </Location> Well, perhasp I miss something but /ldap-status always display : Cache has not been enabled/initialised. Does someone know if LDAP caching is always disabled in 2.0.44 or if I made a mistake ? Bye Laurent
I just make a test w/ latest 2.0.47 It doesn't crash but, /ldap-status says ldap caching is not enabled even if I put directive of my previous messages in the configuration file. I miss something or caching can't be done on my plateforme ? Laurent
Created attachment 8185 [details] My latest patch for ldap cache using shared memory
This is my latest and new patch fixing ldap cache using shared memory. It is different than the latest one and more clean. I fix a bug which could appear when apache is running vhosts I tested it on httpd-2.0.47 and latest cvs version and it's working well on linux ldap-status is displaying the correct information and it's caching ldap request in each vhost using ldap Auth. I added a directive: LDAPSharedCacheFile (filename) i used LDAPSharedCacheFile logs/ldap_cache_file i hope it will work entirely now regards, Matthieu
to summarize a few observations i made with 2.0.47, worker-mpm, solaris8 and openldap2.1.22: 1.) i must place the following statements outside of any virtual host statement otherwise the ldap-cache will not work (checked with the ldap-status handler). LDAPSharedCacheSize 200000 LDAPCacheEntries 1024 <- this seems to be the important one LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 [LDAPSharedCacheFile logs/ldap_cache_file] using this configuration the ldap-cache seems to initialize just fine, e.g. ... Cache Name Entries Avg. Chain Len. Hits Ins/Rem Purges Avg Purge Time LDAP URL Cache 0 (0% full) 0.0 0/0 100% 0/0 (none) 0 ... but after the first successfull authentication the connection aborts. error_log: ... [Sat Sep 20 14:18:35 2003] [notice] child pid 14848 exit signal Bus error (10) ... 2. placing the above statement inside a virtual-host statement or setting the parameter LDAPCacheEntries to 0, results in a disabled LDAP cache, but authentication works at least. 3. applying the latest patch from Matthieu Estrade (09/12/03) doesn't help either. httpd creates a 6 byte LDAPSharedCacheFile, but the results are the same listed in 1) and 2)
For you folks who are getting crashes with the LDAP crashing (exit signal SIGBUS or whatever)... Can you post a backtrace from a core dump pretty please so we know exactly which code is crashing? Thanks!
dumbo:~/apache-2.0.47/bin> ./apachectl startssl Segmentation Fault - core dumped dumbo:~/apache-2.0.47/bin> gdb httpd core GNU gdb 5.3 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.9"... Core was generated by `/home/backuppc/apache-2.0.47/bin/httpd -k start -DSSL'. Program terminated with signal 11, Segmentation fault. Reading symbols from /home/backuppc/apache-2.0.47/lib/libaprutil-0.so.0...done. Loaded symbols for /home/backuppc/apache-2.0.47/lib/libaprutil-0.so.0 Reading symbols from /usr/lib/libldap.so.5...done. Loaded symbols for /usr/lib/libldap.so.5 Reading symbols from /usr/local/lib/liblber.so.2...dbxread.c:1732: gdb-internal-error: sect_index_data not initialized An internal GDB error was detected. This may make further debugging unreliable. Quit this debugging session? (y or n) n Create a core file containing the current state of GDB? (y or n) n Reading symbols from /home/backuppc/apache-2.0.47/lib/libexpat.so.0...done. Loaded symbols for /home/backuppc/apache-2.0.47/lib/libexpat.so.0 Reading symbols from /home/backuppc/apache-2.0.47/lib/libapr-0.so.0...done. Loaded symbols for /home/backuppc/apache-2.0.47/lib/libapr-0.so.0 Reading symbols from /usr/lib/libsendfile.so.1...done. Loaded symbols for /usr/lib/libsendfile.so.1 Reading symbols from /usr/lib/librt.so.1...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 ---Type <return> to continue, or q <return> to quit--- Reading symbols from /usr/lib/libresolv.so.2...done. Loaded symbols for /usr/lib/libresolv.so.2 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/lib/libmd5.so.1...done. Loaded symbols for /usr/lib/libmd5.so.1 Reading symbols from /usr/lib/libaio.so.1...done. Loaded symbols for /usr/lib/libaio.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-Enterprise/lib/libc_psr.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 #0 0xfeeb2f68 in strlen () from /usr/lib/libc.so.1 (gdb) bt #0 0xfeeb2f68 in strlen () from /usr/lib/libc.so.1 #1 0xff16c990 in apr_pstrdup () from /home/backuppc/apache-2.0.47/lib/libapr-0.so.0 #2 0x0002ee48 in mod_auth_ldap_parse_url () #3 0x0006a4ec in invoke_cmd () #4 0x0006bda0 in ap_walk_config_sub () #5 0x0006be9c in ap_walk_config () #6 0x0008bc2c in dirsection () #7 0x0006a36c in invoke_cmd () #8 0x0006bda0 in ap_walk_config_sub () #9 0x0006be9c in ap_walk_config () #10 0x0006d2fc in ap_process_config_tree () #11 0x000716d8 in main () (gdb) quit dumbo:~/apache-2.0.47/bin> .../httpd.conf ============== <Directory "/home/backuppc/apache-2.0.47/cgi-bin"> AllowOverride None Options None Order allow,deny Allow from all AuthName "BackupPC Admin Page" AuthType Basic AuthLDAPEnabled on AuthLDAPAuthoritative on AuthLDAPURL ldap://...obfuscated... require valid-user </Directory> No matter what I put in the AuthLDAPURL config entry, the software segfaults on startup. Looking at the backtrace, it is having trouble parsing the line for some reason. This is Solaris 9 with Apache 2.0.47 compiled with GNU Make 3.80, GCC 3.3 and OpenLDAP 2.1.22. I am not setting any entries related to LDAP caching. The same config entries work fine on Apache 2.0.47 compiled on Linux (RedHat 9, x86).
nice backtrace :) there are a bunch of apr_pstrdup() calls in that function... normal way to get the debugger to tell us is to rebuild the server with debug symbols (add --enable-maintainer-mode to configure invocation), start the server to get a new coredump, and use gdb again... gdb this time should display the actual source file line numbers the ldap function that calls apr_pstrdup() also has a bunch of debug statements... can you try starting Apache with "-e debug" option first to see if mod_auth_ldap's debug messages get to the console or to the error log? if this works, we may be able to get a good hint without you rebuilding your server
my error_log (loglevel debug): ...starting apache... [Sat Sep 27 11:18:23 2003] [notice] LDAP: Built with OpenLDAP LDAP SDK [Sat Sep 27 11:18:23 2003] [notice] LDAP: SSL support unavailable [Sat Sep 27 11:18:23 2003] [info] Init: Initializing OpenSSL library [Sat Sep 27 11:18:23 2003] [info] Init: Seeding PRNG with 512 bytes of entropy [Sat Sep 27 11:18:23 2003] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Sat Sep 27 11:18:24 2003] [info] Init: Generating temporary DH parameters (512/1024 bits) [Sat Sep 27 11:18:24 2003] [debug] ssl_scache_dbm.c(422): Inter-Process Session Cache (DBM) Expiry: old: 0, new: 0, removed: 0 [Sat Sep 27 11:18:24 2003] [info] Init: Initializing (virtual) servers for SSL [Sat Sep 27 11:18:24 2003] [info] Server: Apache/2.0.47, Interface: mod_ssl/2.0.47, Library: OpenSSL/0.9.7b [Sat Sep 27 11:18:24 2003] [notice] LDAP: Built with OpenLDAP LDAP SDK [Sat Sep 27 11:18:24 2003] [notice] LDAP: SSL support unavailable [Sat Sep 27 11:18:24 2003] [info] Init: Initializing OpenSSL library [Sat Sep 27 11:18:25 2003] [info] Init: Seeding PRNG with 512 bytes of entropy [Sat Sep 27 11:18:25 2003] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Sat Sep 27 11:18:25 2003] [info] Init: Generating temporary DH parameters (512/1024 bits) [Sat Sep 27 11:18:25 2003] [info] Init: Initializing (virtual) servers for SSL [Sat Sep 27 11:18:25 2003] [info] Server: Apache/2.0.47, Interface: mod_ssl/2.0.47, Library: OpenSSL/0.9.7b [Sat Sep 27 11:18:25 2003] [debug] util_ldap.c(1104): [5795] ldap cache init: Error 0 [Sat Sep 27 11:18:25 2003] [notice] Apache configured -- resuming normal operations [Sat Sep 27 11:18:25 2003] [info] Server built: Sep 13 2003 13:31:41 [Sat Sep 27 11:18:25 2003] [debug] worker.c(1736): AcceptMutex: pthread (default: pthread) [Sat Sep 27 11:18:42 2003] [notice] child pid 5795 exit signal Bus error (10) [Sat Sep 27 11:18:43 2003] [debug] util_ldap.c(1104): [5796] ldap cache init: Error 0 [Sat Sep 27 11:18:44 2003] [notice] child pid 5796 exit signal Bus error (10) [Sat Sep 27 11:18:45 2003] [debug] util_ldap.c(1104): [5797] ldap cache init: Error 0 [Sat Sep 27 11:19:10 2003] [info] removed PID file /opt/httpd/logs/httpd.pid (pid=5793) [Sat Sep 27 11:19:10 2003] [notice] caught SIGTERM, shutting down ...shutdown... at 11:18:42 i tried to authenticate the first time... output to console on startup: [Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(958): [5792] ldap cache: Setting shared memory cache size to 200000 bytes. [Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(992): [5792] ldap cache: Setting search cache size to 1024 entries. [Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(973): [5792] ldap cache: Setting cache TTL to 600000000 microseconds. [Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(1025): [5792] ldap cache: Setting operation cache size to 1024 entries. [Sat Sep 27 11:18:23 2003] [debug] util_ldap.c(1007): [5792] ldap cache: Setting operation cache TTL to 600000000 microseconds. [Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(737): [5792] auth_ldap url parse: `ldap://localhost:389/CN=AAAA,DC=BBBB,DC=CCCC?DDDD?one? (objectClass=person)' [Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(758): [5792] auth_ldap url parse: Host: localhost [Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(760): [5792] auth_ldap url parse: Port: 389 [Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(762): [5792] auth_ldap url parse: DN: CN=AAAA,DC=BBBB,DC=CCCC [Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(764): [5792] auth_ldap url parse: attrib: DDDD [Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(766): [5792] auth_ldap url parse: scope: onelevel [Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(771): [5792] auth_ldap url parse: filter: (objectClass=person) [Sat Sep 27 11:18:23 2003] [debug] mod_auth_ldap.c(836): LDAP: auth_ldap not using SSL connections ...and a few more of these statements. no core file was created, although coredump's should work # coreadm global core file pattern: init core file pattern: core global core dumps: disabled per-process core dumps: enabled global setid core dumps: disabled per-process setid core dumps: disabled global core dump logging: disabled # coreadm `ps -ef | grep httpd | grep root | awk '{print $2}'` 5529: core # any hints how i can retrieve more helpful informations are appreciated.
okay, this one (being unable to create a core file) was my fault, after adjusting a few paramters if got the desired result: # gdb httpd core GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... Core was generated by `/opt/httpd/bin/httpd -k start'. Program terminated with signal 9, Killed. Reading symbols from /opt/httpd/lib/libaprutil-0.so.0...done. Loaded symbols for /opt/httpd/lib/libaprutil-0.so.0 Reading symbols from /opt/openldap/lib/libldap.so.2...done. Loaded symbols for /opt/openldap/lib/libldap.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /opt/openldap/lib/liblber.so.2...done. Loaded symbols for /opt/openldap/lib/liblber.so.2 Reading symbols from /opt/httpd/lib/libexpat.so.0...done. Loaded symbols for /opt/httpd/lib/libexpat.so.0 Reading symbols from /usr/local/lib/libiconv.so.2...done. Loaded symbols for /usr/local/lib/libiconv.so.2 Reading symbols from /opt/httpd/lib/libapr-0.so.0...done. Loaded symbols for /opt/httpd/lib/libapr-0.so.0 Reading symbols from /usr/lib/libsendfile.so.1...done. Loaded symbols for /usr/lib/libsendfile.so.1 Reading symbols from /usr/lib/librt.so.1...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libresolv.so.2...done. Loaded symbols for /usr/lib/libresolv.so.2 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libaio.so.1...done. Loaded symbols for /usr/lib/libaio.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,UltraAX-i2/lib/libc_psr.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/lib/nss_files.so.1...done. Loaded symbols for /usr/lib/nss_files.so.1 Reading symbols from /opt/httpd/modules/libphp4.so...done. Loaded symbols for /opt/httpd/modules/libphp4.so Reading symbols from /opt/httpd/modules/mod_security.so...done. Loaded symbols for /opt/httpd/modules/mod_security.so #0 0x4a4f8 in util_ald_cache_insert (cache=0xfed501b0, payload=0xfe303828) at util_ldap_cache_mgr.c:396 396 node->add_time = apr_time_now(); (gdb) bt #0 0x4a4f8 in util_ald_cache_insert (cache=0xfed501b0, payload=0xfe303828) at util_ldap_cache_mgr.c:396 #1 0x49184 in util_ldap_cache_checkuserid (r=0x350fe0, ldc=0x20d4a8, url=0x1 <Address 0x1 out of bounds>, basedn=0x36b260 "MyUsername", scope=0, attrs=0x233b00, filter=0xfe3038f0 "(&(objectClass=person)(sAMAccountName=MyUsername))", bindpw=0x36b22f "MyPassword", binddn=0xfe3038e8, retvals=0xfe3038e4) at util_ldap.c:923 #2 0x4af14 in mod_auth_ldap_check_user_id (r=0x350fe0) at mod_auth_ldap.c:366 #3 0xaaa4c in ap_run_check_user_id (r=0x350fe0) at request.c:112 #4 0xab398 in ap_process_request_internal (r=0x350fe0) at request.c:235 #5 0x77b28 in ap_process_request (r=0x350fe0) at http_request.c:286 #6 0x72f7c in ap_process_http_connection (c=0x346ba0) at http_core.c:293 #7 0x9ef6c in ap_run_process_connection (c=0x346ba0) at connection.c:85 #8 0x9f258 in ap_process_connection (c=0x346ba0, csd=0x346ac0) at connection.c:211 #9 0x90448 in process_socket (p=0x346ba0, sock=0x346ac0, my_child_num=0, my_thread_num=2, bucket_alloc=0x2e53e0) at worker.c:632 #10 0x90b34 in worker_thread (thd=0x1e6830, dummy=0x346ba0) at worker.c:947 #11 0xff2756d0 in dummy_worker (opaque=0x1e6830) at thread.c:127 (gdb) quit
SunOS neutrino 5.8 Generic_108528-16 sun4u sparc SUNW,Sun-Fire-480R OpenSSL 0.9.7c OpenLdap 2.1.22 Apache 2.0.47 ./configure --with-ssl --enable-so --enable-ssl --with-ldap --enable-ldap --enable-auth-ldap --enable-proxy --enable-rewrite --enable-maintainer-mode It doesn't coredump, is there a way to keep it in the foreground & debug for more info? Duncan ./httpd -e debug error_log when logging -> debug [Fri Oct 03 12:18:38 2003] [notice] LDAP: Built with OpenLDAP LDAP SDK [Fri Oct 03 12:18:38 2003] [notice] LDAP: SSL support available [Fri Oct 03 12:18:38 2003] [info] Init: Initializing OpenSSL library [Fri Oct 03 12:18:38 2003] [info] Init: Seeding PRNG with 0 bytes of entropy [Fri Oct 03 12:18:38 2003] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Fri Oct 03 12:18:38 2003] [info] Init: Generating temporary DH parameters (512/1024 bits) [Fri Oct 03 12:18:38 2003] [warn] Init: Session Cache is not configured [hint: SSLSessionCache] [Fri Oct 03 12:18:38 2003] [info] Init: Initializing (virtual) servers for SSL [Fri Oct 03 12:18:38 2003] [info] Server: Apache/2.0.47, Interface: mod_ssl/2.0. 47, Library: OpenSSL/0.9.7c [Fri Oct 03 12:18:38 2003] [notice] LDAP: Built with OpenLDAP LDAP SDK [Fri Oct 03 12:18:38 2003] [notice] LDAP: SSL support available [Fri Oct 03 12:18:38 2003] [info] Init: Initializing OpenSSL library [Fri Oct 03 12:18:38 2003] [info] Init: Seeding PRNG with 0 bytes of entropy [Fri Oct 03 12:18:38 2003] [info] Init: Generating temporary RSA private keys (512/1024 bits) [Fri Oct 03 12:18:38 2003] [info] Init: Generating temporary DH parameters (512/1024 bits) [Fri Oct 03 12:18:38 2003] [info] Init: Initializing (virtual) servers for SSL [Fri Oct 03 12:18:38 2003] [info] Server: Apache/2.0.47, Interface: mod_ssl/2.0. 47, Library: OpenSSL/0.9.7c [Fri Oct 03 12:18:38 2003] [debug] util_ldap.c(1104): [5615] ldap cache init: Error 0 [Fri Oct 03 12:18:38 2003] [notice] Apache/2.0.47 (Unix) mod_ssl/2.0.47 OpenSSL/0.9.7c configured -- resuming normal operations [Fri Oct 03 12:18:38 2003] [info] Server built: Oct 3 2003 12:07:30 [Fri Oct 03 12:18:38 2003] [debug] prefork.c(1037): AcceptMutex: pthread (default: pthread) [Fri Oct 03 12:18:38 2003] [debug] util_ldap.c(1104): [5616] ldap cache init: Error 0 [Fri Oct 03 12:18:38 2003] [debug] util_ldap.c(1104): [5617] ldap cache init: Error 0 [Fri Oct 03 12:18:38 2003] [debug] util_ldap.c(1104): [5619] ldap cache init: Error 0 [Fri Oct 03 12:18:39 2003] [debug] util_ldap.c(1104): [5620] ldap cache init: Error 0 [Fri Oct 03 12:19:13 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5615] auth_ldap authenticate: using URL ... [Fri Oct 03 12:19:13 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5616] auth_ldap authenticate: using URL ... [Fri Oct 03 12:19:13 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5617] auth_ldap authenticate: using URL ... [Fri Oct 03 12:19:14 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5619] auth_ldap authenticate: using URL ... [Fri Oct 03 12:19:14 2003] [debug] mod_auth_ldap.c(343): [client xxx] [5620] auth_ldap authenticate: using URL ... [Fri Oct 03 12:19:14 2003] [notice] child pid 5620 exit signal Bus error (10) [Fri Oct 03 12:19:14 2003] [notice] child pid 5619 exit signal Bus error (10) [Fri Oct 03 12:19:14 2003] [notice] child pid 5617 exit signal Bus error (10) [Fri Oct 03 12:19:14 2003] [notice] child pid 5616 exit signal Bus error (10) [Fri Oct 03 12:19:14 2003] [notice] child pid 5615 exit signal Bus error (10) [Fri Oct 03 12:19:14 2003] [debug] util_ldap.c(1104): [5644] ldap cache init: Error 0 [Fri Oct 03 12:19:15 2003] [debug] util_ldap.c(1104): [5646] ldap cache init: Error 0 [Fri Oct 03 12:19:15 2003] [debug] util_ldap.c(1104): [5647] ldap cache init: Error 0 [Fri Oct 03 12:19:16 2003] [debug] util_ldap.c(1104): [5651] ldap cache init: Error 0 [Fri Oct 03 12:19:16 2003] [debug] util_ldap.c(1104): [5653] ldap cache init: Error 0 [Fri Oct 03 12:19:16 2003] [debug] util_ldap.c(1104): [5652] ldap cache init: Error 0 [Fri Oct 03 12:19:16 2003] [debug] util_ldap.c(1104): [5657] ldap cache init: Error 0 [Fri Oct 03 12:19:18 2003] [info] removed PID file /etc/apache2/logs/httpd.pid (pid=5614) [Fri Oct 03 12:19:18 2003] [notice] caught SIGTERM, shutting down
Hello All, I just compiled Apache 2.0.47 using ldap modules on Solaris with ldap libraires generated by compiling OpenLDAP 2.1.23. Apache core dump systematically in the mod_auth_ldap_parse_url function. Apparently the ldap url is never correctly parsed. When I'm trying to access a page protected by an LDAP .htaccess, the child crashs and generates the following errors log on LDAP url parsing with strange server and port info: [Wed Oct 22 17:52:32 2003] [debug] prefork.c(1037): AcceptMutex: pthread (default: pthread) [Wed Oct 22 17:52:39 2003] [debug] mod_auth_ldap.c(737): [25927] auth_ldap url parse: `ldap://myserver:389/mysearchbase?sAMAccountName?sub?(objectClass=*)' [Wed Oct 22 17:52:39 2003] [debug] mod_auth_ldap.c(758): [25927] auth_ldap url parse: Host: mysearchbase [Wed Oct 22 17:52:39 2003] [debug] mod_auth_ldap.c(760): [25927] auth_ldap url parse: Port: 1230072 [Wed Oct 22 17:52:40 2003] [notice] child pid 25927 exit signal Segmentation fault (11) When I include the LDAP restrictions in my httpd.conf file, apachectl core dumps in the LDAP url parsing too. Here is the gdb traces: #0 0x0002ae14 in mod_auth_ldap_parse_url (cmd=0xffbefbd8, config=0xdfb20, url=0xdfc20 "ldap://myserver:389/searchBase?sAMAccountName?sub? (objectClass=*)") at mod_auth_ldap.c:764 764 ap_log_error(APLOG_MARK, APLOG_DEBUG|APLOG_NOERRNO, 0, My configure options were: ./configure --prefix=/usr/local/apache2_withldap --enable-so --with-ldap -- enable-ldap --enable-auth-ldap --libdir=/usr/local/openldap-2.1.23/li b --includedir=/usr/local/openldap-2.1.23/include Here is my .htaccess file: AuthName "RCS Staff only" AuthType Basic AuthLDAPEnabled on AuthLDAPAuthoritative on #AuthLDAPBindDN username #AuthLDAPBindPassword password AuthLDAPURL "ldap://myserver:389/mysearchbase?sAMAccountName?sub(objectClass=*)" require valid-user I followed the temporary workaround (disabling ldap cache) and recompile Apache after adding the last patch without success. Christian
Hi, For the last comment, i agree it's not normal apache segfault parsing the url, You seem want to do authentication against active directory which is impossible with mod_auth_ldap. Dealing with active directory for user/access is different than ldap auth. First you have to bind with a authorized user/pass to the active directory and get the name of the user (not the login), then you have to bind with this name and password you receive and look if bind is ok, if bind ok, then the user is valid. I should get an access on a solaris (sparc) box soon (finally) and then continue working on all these bugs. Somebody could tell me with which compiler (gcc or sun) did they use to compile Apache ? Matthieu
Patch id #8185 appears to work fine on FreeBSD 4.8-STABLE.
Hi, I'm using the following combinations with netscape sdk: Solaris 9 with gcc version 3.3 Solaris 8 with gcc version 2.95.3 Both combinations produce the error "exit signal Bus error". Erwin
What happened to the developer that made the changes that broke it? Why doesn't someone roll the changes back? It worked fine before. It's been broken for 8 months now. This is ridiculus.
I dunno what you want to roll back, but after check again the CVS, nothing important has been done after the port of ldap cache to apache 2.0., and it's older more than 1 year... Maybe you speak about apache 1.3 ?? I agree it maybe worked with mpm prefork, a lucky day, but be sure that considering what the patch do, it's impossible it worked a day with mpm using threads. For the developper who did "the changes that brokes it", i hope he is still alive and i don't think somebody should do something to him, even if he did an error. I think people are doing here an effort to make the shared memory ldap cache working better and be stable, so please don't post such message if you find it ridiculous...
All I know is that I had it working fine with 2.0.44. They made changes in 2.0.45 including changes in the syntax for using TLS/SSL and it hasn't worked since.
Hi again jemiller, To help, you could tell us what OS are you using, the LDAP library you are using, if you setup cache, the mpm you compiled with, and if you applyied one patch posted here. Them if your problem is when you startup apache -> so probably the url parsing problem Or if the problem is when a client is trying to authenticate. -> so probably the cache problem. Thanks in advance
My original bug report is located at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=19993. I just tried it again using Solaris 8 with a recent patch cluster installed, Apache 2.0.48, OpenLDAP 2.1.23, and OpenSSL 0.9.7c. I'm using the default cache setting. According the the configure log, it's using "prefork" MPM. I didn't use any patches. I used the following command line to configure it. CPPFLAGS=-I/opt/include LDFLAGS=-L/opt/lib ./configure -- prefix=/opt/pkgs/httpd-2.0.48 --enable-ssl --with-ldap --enable-ldap --enable- auth-ldap 2>&1 | tee configure.txt According the the LDAP server logs, it is able to connection and bind successfully. I receive the following error in the error_log file. [Thu Nov 06 15:35:56 2003] [notice] child pid 24270 exit signal Bus error (10) Also, it doesn't appear to be using TLS like it should be. Until version 2.0.45, you could use the AuthLDAPStartTLS directive to enable TLS. In version 2.0.45, according to the documentation you have to use LDAPTrustedCA and LDAPTrustedCAType directives (AuthLDAPStartTLS is no longer recognized). This seemed to work in version 2.0.45. However, now, it doesn't seem to work. To work around that problem, I reconfigured my LDAP server to allow non- encrypted binds. This resulted in the bus error listed above.
New patch fixing another possible segfault condition. You can find all patches and howto at the following address: http://www.apache.org/~trawick/ ldap.20031107.readme and ldap.20031107.tar.gz Please when you report bugs here, be sure you applied correctly all patches. You can also use CVS to checkout the latest and patched code of HTTP (2.1) Thanks for your help
The patch ldap.20031107.tar.gz works for me on Solaris 9 and Apache 2.0.48 with most simply settings (no ldap cache directives): <LocationMatch / > AuthName "some realm" AuthType basic AuthLDAPEnabled on AuthLDAPURL "<ldap-url>" AuthLDAPAuthoritative on require valid-user </LocationMatch> Thanks
results when using the new patch (from Matthieu): system: SunOS 5.8 Generic_108528-23 sun4u sparc SUNW,UltraAX-i2 OpenSSL 0.9.7c OpenLdap 2.1.23 Apache 2.0.48 this time i even have to use the LDAPSharedCacheFile statement to enable the LDAP Cache, my settings: LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 LDAPSharedCacheFile logs/ldap_cache_file if i do not use this tag, the ldap-cache will not become initialized (verified with ldap-status) but authentication works ok. nevertheless enabling the ldap-cache and authenticating a user with the correct password results in the following message in the error log [Fri Nov 07 22:20:31 2003] [notice] child pid 29464 exit signal Bus error (10), possible coredump in /opt/httpd backtrage of core file: (gdb) bt #0 util_ald_create_cache (st=0x1eab08, hashfunc=0x49b90 <util_ldap_search_node_hash>, comparefunc=0x49ba8 <util_ldap_search_node_compare>, copyfunc=0x49bc8 <util_ldap_search_node_copy>, freefunc=0x49cfc <util_ldap_search_node_free>) at util_ldap_cache_mgr.c:330 #1 0x4a44c in util_ald_create_caches (st=0x1eab08, url=0x1db410 "ldap://host:389/CN=Users,DC=part1,DC=part2?sAMAccountName? one?(objectClass=person)") at util_ldap_cache_mgr.c:258 #2 0x48f24 in util_ldap_cache_checkuserid (r=0x30dd90, ldc=0x20db28, url=0x1db410 "ldap://host:389/CN=Users,DC=part1,DC=part2?sAMAccountName? one?(objectClass=person)", basedn=0x1db480 "CN=Users,DC=part1,DC=part2", scope=1, attrs=0x1db4a0, filter=0xfe2018f0 "(&(objectClass=person)(sAMAccountName=username))", bindpw=0x30faef "password", binddn=0xfe2018e8, retvals=0xfe2018e4) at util_ldap.c:764 #3 0x4b228 in mod_auth_ldap_check_user_id (r=0x30dd90) at mod_auth_ldap.c:366 #4 0xab174 in ap_run_check_user_id (r=0x30dd90) at request.c:112 #5 0xabac0 in ap_process_request_internal (r=0x30dd90) at request.c:235 #6 0x77f90 in ap_process_request (r=0x30dd90) at http_request.c:286 #7 0x73378 in ap_process_http_connection (c=0x2e6890) at http_core.c:293 #8 0x9f66c in ap_run_process_connection (c=0x2e6890) at connection.c:85 #9 0x9f958 in ap_process_connection (c=0x2e6890, csd=0x2e67a0) at connection.c:211 #10 0x90964 in process_socket (p=0x2e6890, sock=0x2e67a0, my_child_num=0, my_thread_num=3, bucket_alloc=0x2f7d88) at worker.c:632 #11 0x91044 in worker_thread (thd=0x1eb510, dummy=0x3) at worker.c:946 #12 0xff275d84 in dummy_worker (opaque=0x1eb510) at thread.c:127 if anyone needs more informations or if i should test anything feel free to ask... have a nice day, MarkuS
All built from Source from CVS -HEAD OS: FreeBSD 5.1-CURRENT backtrace: #0 apr_rmm_calloc (rmm=0xd0d0d0d0, reqsize=99) at apr_rmm.c:344 #1 0x2908c8a2 in util_ald_alloc (cache=0x8139288, size=3503345872) at util_ldap_cache_mgr.c:141 #2 0x2908cbc0 in util_ald_create_cache (st=0x80d15b8, hashfunc=0xd0d0d0d0, comparefunc=0xd0d0d0d0, copyfunc=0xd0d0d0d0, freefunc=0xd0d0d0d0) at util_ldap_cache_mgr.c:304 #3 0x2908c804 in util_ldap_cache_init (pool=0x809b018, st=0x80d15b8) at util_ldap_cache.c:324 #4 0x2908c044 in util_ldap_post_config (p=0x809b018, plog=0x80c5018, ptemp=0x80c7018, s=0x80b51e0) at util_ldap.c:1147 #5 0x08063752 in ap_run_post_config (pconf=0x809b018, plog=0x80c5018, ptemp=0x80c7018, s=0x80b51e0) at config.c:131 #6 0x08068658 in main (argc=3, argv=0xbfbffb48) at main.c:618 #7 0x0805c269 in _start () It seems that in util_ldap_cache_mgr.c around line 300 we do this: #if APR_HAS_SHARED_MEMORY cache = (util_ald_cache_t *)util_ald_alloc(st->cache_rmm, sizeof(util_ald_cache_t)); #else But the util_ald_alloc function expects a util_ald_cache_t type, and we are passing in a apr_rmm_t. util_ald_alloc then does: if (cache->rmm_addr) { /* allocate from shared memory */ return (void *)apr_rmm_addr_get(cache->rmm_addr, apr_rmm_calloc(cache->rmm_addr, size)); } Since we passed in an apr_rmm_t, it does a nice crash when we try todo all the stuff with cache->rmm_addr.
Solaris 8 OpenLDAP 2.1.23 Apache 2.0.48 with Mathieu's patch Same problems as everyone else reports. Apache child processes die with bus errors on the first LDAP query. Applying the patch recommended above had no effect whatsoever. I get bus errors multiple times, but I cannot get it to dump core anywhere.
Nevermind, I figured it out. Sorry for the double. GNU gdb 5.0 Copyright 2000 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... Core was generated by `bin/httpd -f conf/MYSITE_CENSORED.com.conf -k start'. Program terminated with signal 9, Killed. Reading symbols from /usr/local/apache2/lib/libaprutil-0.so.0...done. Loaded symbols for /usr/local/apache2/lib/libaprutil-0.so.0 Reading symbols from /usr/local/lib/libldap.so.2...done. Loaded symbols for /usr/local/lib/libldap.so.2 Reading symbols from /usr/lib/libgen.so.1...done. Loaded symbols for /usr/lib/libgen.so.1 Reading symbols from /usr/local/ssl/lib/libssl.so.0.9.7...done. Loaded symbols for /usr/local/ssl/lib/libssl.so.0.9.7 Reading symbols from /usr/local/ssl/lib/libcrypto.so.0.9.7...done. Loaded symbols for /usr/local/ssl/lib/libcrypto.so.0.9.7 Reading symbols from /usr/local/lib/liblber.so.2...done. Loaded symbols for /usr/local/lib/liblber.so.2 Reading symbols from /usr/local/BerkeleyDB.4.1/lib/libdb-4.1.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.1/lib/libdb-4.1.so Reading symbols from /usr/local/lib/libexpat.so.0...done. Loaded symbols for /usr/local/lib/libexpat.so.0 Reading symbols from /usr/local/apache2/lib/libapr-0.so.0...done. Loaded symbols for /usr/local/apache2/lib/libapr-0.so.0 Reading symbols from /usr/lib/libsendfile.so.1...done. Loaded symbols for /usr/lib/libsendfile.so.1 Reading symbols from /usr/lib/librt.so.1...done. Loaded symbols for /usr/lib/librt.so.1 Reading symbols from /usr/lib/libm.so.1...done. Loaded symbols for /usr/lib/libm.so.1 Reading symbols from /usr/lib/libsocket.so.1...done. Loaded symbols for /usr/lib/libsocket.so.1 Reading symbols from /usr/lib/libnsl.so.1...done. Loaded symbols for /usr/lib/libnsl.so.1 Reading symbols from /usr/lib/libresolv.so.2...done. Loaded symbols for /usr/lib/libresolv.so.2 Reading symbols from /usr/lib/libdl.so.1...done. Loaded symbols for /usr/lib/libdl.so.1 Reading symbols from /usr/lib/libpthread.so.1...done. Loaded symbols for /usr/lib/libpthread.so.1 Reading symbols from /usr/lib/libc.so.1...done. Loaded symbols for /usr/lib/libc.so.1 Reading symbols from /usr/local/lib/libgcc_s.so.1...done. Loaded symbols for /usr/local/lib/libgcc_s.so.1 Reading symbols from /usr/lib/libaio.so.1...done. Loaded symbols for /usr/lib/libaio.so.1 Reading symbols from /usr/lib/libmp.so.2...done. Loaded symbols for /usr/lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1 Reading symbols from /usr/lib/libthread.so.1...done. Loaded symbols for /usr/lib/libthread.so.1 Reading symbols from /usr/lib/nss_nisplus.so.1...done. Loaded symbols for /usr/lib/nss_nisplus.so.1 Reading symbols from /usr/lib/libdoor.so.1...done. Loaded symbols for /usr/lib/libdoor.so.1 #0 util_ald_create_cache (st=0x105048, hashfunc=0x32068 <util_ldap_search_node_hash>, comparefunc=0x3207c <util_ldap_search_node_compare>, copyfunc=0x320a0 <util_ldap_search_node_copy>, freefunc=0x321c4 <util_ldap_search_node_free>) at util_ldap_cache_mgr.c:332 332 util_ldap_cache_mgr.c: No such file or directory. (gdb) bt #0 util_ald_create_cache (st=0x105048, hashfunc=0x32068 <util_ldap_search_node_hash>, comparefunc=0x3207c <util_ldap_search_node_compare>, copyfunc=0x320a0 <util_ldap_search_node_copy>, freefunc=0x321c4 <util_ldap_search_node_free>) at util_ldap_cache_mgr.c:332 #1 0x328a8 in util_ald_create_caches (st=0x0, url=0x10e9d8 "ldap://CENSORED:389/o=CENSORED,c=us?uid?sub") at util_ldap_cache_mgr.c:258 #2 0x31834 in util_ldap_cache_checkuserid (r=0x179558, ldc=0x114468, url=0x10e9d8 "ldap://CENSORED:389/o=CENSORED,c=us?uid?sub", basedn=0x10ea20 "o=CENSORED,c=us", scope=2, attrs=0x10ea30, filter=0xfdd07960 "(&(objectclass=*)(uid=CENSORED)) ", bindpw=0x17b304 "MY_PLAINTEXT_PASSWORD", binddn=0xfdd07958, retvals=0xfdd07954) at util_ldap.c:764 #3 0x335ac in mod_auth_ldap_check_user_id (r=0x179558) at mod_auth_ldap.c:366 #4 0x802ac in ap_run_check_user_id (r=0x179558) at request.c:112 #5 0x80b64 in ap_process_request_internal (r=0x179558) at request.c:259 #6 0x54ac4 in ap_process_request (r=0x179558) at http_request.c:286 #7 0x4ffb4 in ap_process_http_connection (c=0x173630) at http_core.c:293 #8 0x74d50 in ap_run_process_connection (c=0x173630) at connection.c:85 #9 0x66298 in process_socket (p=0x173508, sock=0x173540, my_child_num=0, my_thread_num=0, bucket_alloc=0x177518) at worker.c:632 #10 0x669c0 in worker_thread (thd=0x115570, dummy=0x173508) at worker.c:946 #11 0xfef9459c in dummy_worker (opaque=0x115570) at thread.c:127 (gdb)
And again ... Wish I could edit comments. I manually defined APR_HAS_SHARED_MEMORY to be 0 and I successfully got the LDAP cache functionality to work without erroring. The relevant file is modules/experimental/util_ldap_cache_mgr.c. You basically want it to use the calloc() and free() functions instead of the apr_rmm_xxxx functions. I hope this points someone in the right direction to make a real fix, but if you absolutely need this functionality, this is how you can get it. Sorry, I have no official patch, because this is a temporary hack to get this to work in my environment. Solaris 8, OpenLDAP 2.1.23, Apache 2.0.48 (with Matthieu's patch)
Hi, As you said it's a hack to work in your environment. Adding and modifying the Tags for SHM just disabled it, and no, we have to make it work with shm :) Disabling shm, you make the ldap cache not working well on threaded mpm. For example, with worker mpm, you will have a cache context for all forked server, and only thread inside will be able to use the cache, in each server. Shared memory is providing a common cache data for all threaded and forked server. So yes, you did a hack to make it work, but it's not a solution here :) What i will do in the next patch is to display in debug mode, which memory management it will use, and continue effort to make it stable. Matthieu
enabling the PatchAvailable keyword updated doc on submitting patches is at http://httpd.apache.org/dev/patches.html
Hi all, my Problem in this Kontext: if i add the line AuthLDAPURL in httpd.conf i cant start apache without SIGSEGV. System is: Solaris 8 gcc 3.1 httpd 2.0.48 openssl 0.9.7c openldap 2.1.25 my ConfigureScript looks like: LIBS="-L/opt/openldap/current/lib" \ INCLUDES="-I/opt/openldap/current/include" \ ./configure \ --disable-autoindex \ --disable-asis \ --disable-userdir \ --disable-cgid \ --disable-cgi \ --disable-imap \ --enable-info \ --enable-proxy \ --enable-ssl \ --enable-headers \ --enable-ldap \ --enable-auth-ldap \ --with-ssl=/opt/openssl/current \ --with-ldap \ --with-mpm=worker httpd.conf: ------------------------------ ...... ........ LDAPSharedCacheSize 200000 LDAPCacheEntries 1024 LDAPCacheTTL 600 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 600 <VirtualHost 10.1.1.11:443> ServerName test .... ... <Location /cbt> # AuthType Basic # AuthName cbt # AuthUserFile conf/auth_user_file # require valid-user AuthLDAPEnabled on AuthLDAPAuthoritative on AuthLDAPURL "ldap://ldap.net.de/c=DE" require valid-user </Location> ......... ........ ....... </VirtualHost> ------------------------------------------- when i uncomment the line: AuthLDAPURL "ldap://ldap.net.de/c=DE" i can start Apache. here ist my Backtrace: ------------------------------------------- GNU gdb 6.0 Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"... Core was generated by `/opt/webservers/apache/test0/2.0.48/bin/httpd -k st'. Program terminated with signal 11, Segmentation fault. Reading symbols from /opt/webservers/apache/test0/2.0.48/lib/libaprutil- 0.so.0...done. Loaded symbols for /opt/webservers/apache/test0/2.0.48/lib/libaprutil-0.so.0 Reading symbols from /usr/local/lib/libldapssl30.so...done. Loaded symbols for /usr/local/lib/libldapssl30.so Reading symbols from /opt/webservers/apache/test0/2.0.48/lib/libexpat.so.0...done. Loaded symbols for /opt/webservers/apache/test0/2.0.48/lib/libexpat.so.0 Reading symbols from /usr/local/lib/libiconv.so.2...done. Loaded symbols for /usr/local/lib/libiconv.so.2 Reading symbols from /opt/webservers/apache/test0/2.0.48/lib/libapr- 0.so.0...done. Loaded symbols for /opt/webservers/apache/test0/2.0.48/lib/libapr-0.so.0 Reading symbols from /lib/libsendfile.so.1...done. Loaded symbols for /lib/libsendfile.so.1 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/libm.so.1...done. Loaded symbols for /lib/libm.so.1 Reading symbols from /lib/libsocket.so.1...done. Loaded symbols for /lib/libsocket.so.1 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /lib/libdl.so.1...done. Loaded symbols for /lib/libdl.so.1 Reading symbols from /lib/libpthread.so.1...done. Loaded symbols for /lib/libpthread.so.1 Reading symbols from /lib/libc.so.1...done. Loaded symbols for /lib/libc.so.1 Reading symbols from /lib/libthread.so.1...done. Loaded symbols for /lib/libthread.so.1 Reading symbols from /lib/libaio.so.1...done. Loaded symbols for /lib/libaio.so.1 Reading symbols from /lib/libmp.so.2...done. Loaded symbols for /lib/libmp.so.2 Reading symbols from /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1...done. Loaded symbols for /usr/platform/SUNW,Ultra-250/lib/libc_psr.so.1 #0 0xfee33174 in strlen () from /lib/libc.so.1 (gdb) run Starting program: /opt/webservers/apache/test0/2.0.48/bin/httpd [New LWP 1] [New LWP 2] [New LWP 3] [New LWP 4] Program received signal SIGSEGV, Segmentation fault. 0xfee33174 in strlen () from /lib/libc.so.1 (gdb) ------------------------------------------- So i read all the Reports, is there a Patch for this Problem ?? I read something about caching and shm but i dont really know, i think my Bug is a little diffrent. Steve Waltner had the same Problem in 2003 i think. i'd like to know what is happening with this bug ? its NEW since beginning of 2003 friendly Regards Christian
Note: I still get the core dump when I apply the very latest (i.e. latest available yesterday) sources from the Apache 2.0 branch. On a positive note, these just compile against 2.0.48 and don't have to be fiddled with (like those from Apache 2.1 did to work with 2.0.48). Unfortunately, the core dump on first attempt to authenticate with the cache enabled is still there. [2.0.48, worker, Solaris 8]
Backtrace (using latest 2.0 branch sources for util_ldap and mod_auth_ldap + 2.0.48 base): current thread: t@6 =>[1] util_ald_create_cache(0xb7688, 0xfea53cb8, 0xfea53cd0, 0xfea53cf0, 0xfea53e20, 0x148), at 0xfea54850 [2] util_ald_create_caches(), at 0xfea545e0 [2] util_ald_create_caches(0xb7688, 0xd81f0, 0x84da0, 0x0, 0xfea33623, 0x6e), at 0xfea545e0 [3] util_ldap_cache_checkuserid(r = 0x15b0c8, ldc = 0xfda00, url = 0xd81f0 "ld ap://jholle03l.ptcnet.ptc.com/ou=people,cn=pdm7,cn=jholle03l,cn=Application%20Se rvices,o=ptc", basedn = 0xd8270 "ou=people,cn=pdm7,cn=jholle03l,cn=Application S ervices,o=ptc", scope = 2, attrs = (nil), filter = 0xfd8058f0 "(&(objectclass=*) (uid=wcadmin))", bindpw = 0x15c5d0 "wcadmin", binddn = 0xfd8058e8, retvals = 0xfd8058e4), line 725 in "util_ldap.c" [4] mod_auth_ldap_check_user_id(r = 0x15b0c8), line 327 in "mod_auth_ldap.c" [5] ap_run_check_user_id(0x15b0c8, 0x62c00, 0x0, 0x2d, 0x29, 0x15b248), at 0x4c784 [6] ap_process_request_internal(0x15b0c8, 0x0, 0x4, 0x15b0c8, 0x60000, 0x15bdc8), at 0x4d0d0 [7] ap_process_request(0x15b0c8, 0xc8, 0x15b0c8, 0x14b178, 0x0, 0x0), at 0x321c0 [8] ap_process_http_connection(0x14b178, 0x2d55c, 0x79400, 0x79400, 0x0, 0x14b1cd), at 0x2d5a8 [9] ap_run_process_connection(0x14b178, 0x80000000, 0x14b088, 0x1, 0x14b170, 0x159088), at 0x40eec [10] ap_process_connection(0x14b178, 0x14b088, 0x14b088, 0x1, 0x14b170, 0x159088), at 0x411d8 [11] process_socket(0x14b178, 0x14b088, 0x0, 0x1, 0x159088, 0x0), at 0x335b8 [12] worker_thread(0x0, 0x1, 0x5c400, 0x5c400, 0x1117e, 0x9d410), at 0x33c98 [13] dummy_worker(0x9d410, 0xfebd5d10, 0x0, 0x5, 0x1, 0xfe401000), at 0xfef15838
This appears to be triggering a gcc on Sparc bug -- read on... Note the backtrace given above was hard to obtain, e.g. I could only obtain it when *not* using maintainer mode on configure, etc. Once I put breakpoints in the routine in question in each child process I could single step through the assembly (for some reason I did not have source- level information even when building with maintainer mode enabled and thus -g - - pointers as to how this might happen would be appreciated) until it blew up. The offending assembly instruction is 'std' (this is on Sparc Solaris 8) and the error is an invalid alignment error. This smelled of a compiler bug -- and sure enough google has lots of claims of various versions of gcc making 8- byte alignment assumptions when it can't legitimately do so -- and then using ldd and std instructions which require such alignment. Thus seeing this only as assembly was not a bad thing -- except that I need to carefully verify which struct field its blowing up on... Does anyone know of a gcc version that is known to have this error fixed? Alternatively, does someone know of flags to pass gcc to work around this? Note this error appears to be specific to -O2 optimization (which I removed from my configure env vars, but I can't seem to get rid of it). Ideally the source for this module or the gcc compilation options for just it (not all of Apache) could be adjusted to skirt this issue. I'll be playing with the possibilities here... [I'm currently still using the ancient gcc 2.95.2 as it's what's already installed on the machine.]
I *believe* that the field causing issues (from the latest Apache 2 branch sources) is avg_purgetime. I'll try replacing it with a float tomorrow as a double seems unnecessary (apart from an insignificant purge speed difference).
Okay on a little further examination I am still getting an alignment bus error from an std instruction BUT it would appear all the structure offsets are 8- byte aligned -- which I guess means the structure allocated by APR's rmm is not?!? If so, this would appear *not* to be the gcc bug. This all seems hard to believe... [I applied the latest apr_rmm.c to no avail.] Note that diffing the rudedog.org and latest Apache 2 sources for util_ldap_cache_mgr.c seems to indicate that the main switch in the routine that's crashing is from MM to APR's rmm....
I have finally cried "uncle" for now (i.e. given up) and am simply replacing all "#if APR_HAS_SHARED_MEMORY" occurences with "#if 0" in the mod_ldap .c files (I left the headers alone). This results in 1 LDAP cache per process. I was already using mod_worker, so now I'm just increasing the number of threads per process a bit and thus limiting the number of processes and thus limiting the number of redundant LDAP caches and entries. The result seems to work just fine -- and should be faster than disabling the cache entirely.
Has the issue where the apr_rmm_*alloc return values are ignored been fixed?
Has an official fix for this bug been created? I've been able to work around this using the disable shared memory hack, but that is not an elegant solution. This bug does not appear in the httpd delivered with Fedora Core 1, but I need to compile my own, and am bouncing into this issue. Any help would be appreciated.
Note: I got what appears to be the same exact crash with a mod_worker Apache 2.0.48 + latest LDAP related patches from 2.0 branch (same stuff I tested on Solaris) built with iPlanet LDAP SDK. As soon as I applied the patch to pretend shared memory does not exist in to the module sources, it seemed to work fine... Whatever the problem is, shm, rmm, or mod/util_ldap, a fix would be *very* much appreciated!
Ooops. I forgot to include the most relevant piece of information in my last comment. The Apache I just tested was on AIX 5.1. Thus this is by no means limited to Solaris.
*** Bug 28716 has been marked as a duplicate of this bug. ***
Can someone confirm whether this bug still bites using the latest LDAP from v2.1.0-dev? There have been a number of bugfix commits, I would like to know if this bug has been squashed.
I can confirm that this bug exists in 2.0.49 (with or without Brad Nicholes latest changes to squash the authenticated LDAP access issues). I have not tried 2.1.0 anything. Also, the cache overflow crash is still present in 2.0.49. [I forget the bug #, but when more distinct users authenticate against Apache than what you've sized the cache for the child process will die. If this does not happen on cache size + 1 users it always happens by cache size + 5 or so users.] Squashing these 2 issues would do wonders for LDAP authentication via Apache and would, in my opinion, justify moving this module out of experimental. Both of these issues are pretty severe, however. They don't preclude use of the module for LDAP authentication, but they require some hefty workarounds (disabling cache sharing between processes and sizing the LDAP cache to hold your entire user population -- which may be excessive).
Note to all: this bug report is discussing many different bugs in the same place. These include: - crash inside mod_auth_ldap_parse_url(): #21719 - crash in LDAP cache util_ldap_search_node_copy(): #28250 - crashes when distinct users exceeds LDAPCacheEntries: #24801 I think it would be more helpful to continue the discussion under each specific report above.
Hmmm... I guess I don't know where exactly it crashes recently, but at least one of my previous notes was of it crashing in util_ald_create_cache(). In any event, I consistently have it crash on the very first request requiring LDAP authentication (with 2.0.49 on Solaris and AIX, but not on Windows) unless/until I disable sharing of the caches across processes -- at which point I only have the cache overflow issue, which I agree is a very separate and distinct bug.
So if I am understanding right, sharing across processes causes an immediate crash, while sharing across threads works - until the cache is full, then crash?
Try this patch attached to bug 24801: http://nagoya.apache.org/bugzilla/showattachment.cgi?attach_id=11633
Yep!
Yup the patch works, or yup that was the problem...? :)
Yup, that was the problem. I've not had a chance to test the patch yet. I will try to get to it today.
Patches for fixing the segfaults have been applied to v2.1.0-dev and v2.0.50-dev. The underlying brokenness that caused the segfaults remains however, and is described in bug 29207. I'm marking this bug as a duplicate of that one to continue getting to the root of the problem. *** This bug has been marked as a duplicate of 29207 ***