Forwarding a reports that's bounced around many corners of the mandrake online presence. I'm not subscribed to this cooker list, so if you reply, pleaser make sure to include me on the reply, thanks.
C -- Craig's PGP Key <http://www.hughes-family.org/craig/pgpkey.html> Get PGP, use it. -----Original Message----- From: civileme [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 21, 2001 11:39 AM To: Craig R Hughes; [EMAIL PROTECTED] Subject: Re: Request bugzilla bug-creation access On Wednesday 21 November 2001 12:46 am, Craig R Hughes wrote: > Hi! I've just jumped through a number of hoops fruitlessly and was > hoping you could help. I tried to mail the email address listed in the > RPM files discussed below first, but that bounced with a message to go > to the bugzilla site. Went there, couldn't find the problem described. > Then tried to create a new bug, couldn't do that, was bounced to the > Mandrake Experts site. That doesn't really seem like the right place > for my comments. I've attached the original email I composed below, and > think it really ought to be filed as a bug. I've put a reasonably large > amount of time into tracking this down, and thought you guys might be > able to benefit from that. > > _____ > > > It looks to me like there's a problem between recent libsasl7 versions > and the imap distribution in the latest cooker that's causing php-imap > to break. > > I am using imap-2000c-7mdk and libsasl7-1.5.17-2mdk and > libsasl7-plug-crammd5-1.5.17-2mdk along with mod_php-4.0.6-7mdk and > php-imap-4.0.6-3mdk (all from current cooker). This is on kernel 2.4.13 > (from linus' tree, not mandrake modified one) on a dual-athlon machine, > but I don't think either of these matter. > > When PHP tries to connect to my IMAP server, I see the following under > strace on the apache process: > > ... > [pid 8533] fstat64(11, {st_mode=S_IFREG|0644, st_size=43, ...}) = 0 > [pid 8533] old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40c76000 > [pid 8533] read(11, "127.0.0.1\t\tlocalhost.localdomain"..., 4096) = 43 > [pid 8533] close(11) = 0 > [pid 8533] munmap(0x40c76000, 4096) = 0 > [pid 8533] alarm(0) = 0 > [pid 8533] time(NULL) = 1006330492 > [pid 8533] time(NULL) = 1006330492 > [pid 8533] select(11, NULL, [10], [10], NULL) = 1 (out [10]) > [pid 8533] time(NULL) = 1006330492 > [pid 8533] write(10, "00000001 AUTHENTICATE CRAM-MD5\r\n", 32) = 32 > [pid 8533] time(NULL) = 1006330492 > [pid 8533] time(NULL) = 1006330492 > [pid 8533] select(11, [10], NULL, [10], NULL) = 1 (in [10]) > [pid 8533] time(NULL) = 1006330492 > [pid 8533] read(10, "+ PDM2MzcxMDU2NTAuMTY0NzQ4MDdAYm"..., 8192) = 72 > [pid 8533] alarm(0) = 0 > [pid 8533] alarm(0) = 0 > [pid 8533] alarm(0) = 0 > [pid 8533] --- SIGSEGV (Segmentation fault) --- > [pid 8533] chdir("/tmp") = 0 > [pid 8533] rt_sigaction(SIGSEGV, {SIG_DFL}, {SIG_DFL}, 8) = 0 > [pid 8533] getpid() = 8533 > [pid 8533] kill(8533, SIGSEGV) = 0 > [pid 8533] sigreturn() = ? (mask now []) > [pid 8533] --- SIGSEGV (Segmentation fault) --- > [pid 8528] <... select resumed> ) = ? ERESTARTNOHAND (To be > restarted) > [pid 8528] --- SIGCHLD (Child exited) --- > [pid 8528] select(0, NULL, NULL, NULL, {0, 340000}) = 0 (Timeout) > [pid 8528] time(NULL) = 1006330492 > > ... > Basically, the PHP script is opening the connection to the server fine, > telling the IMAP server it wants to do CRAM-MD5, and then receiving the > challenge string from the server. Then, it abruptly segfaults. > > So I got the SRPMs for imap and libsasl and re-compiled. Then I took > the unstripped binary DLLs out of the build trees (compiled with -g > flag) and replaced the DLLs in /usr/lib, then changed some apache > options to get it to give me a core file for the dead child process. > The core file yields: > > (gdb) where > #0 0x40a1ec34 in Encode (output=0x5 <Error reading address 0x5: No such > process>, input=0xbfff0f20, len=16) at md5.c:295 > #1 0x40a1e0bd in MD5Final (digest=0x5 <Error reading address 0x5: No > such process>, context=0xbfff0f20) at md5.c:180 > #2 0x40a1f320 in hmac_md5 (text=0x8274068 > "<[EMAIL PROTECTED]>", text_len=50, > key=0xbfff13c0 "glurpie", key_len=7, > digest=0x5 <Error reading address 0x5: No such process>) at > md5.c:518 > #3 0x40a53fd5 in auth_md5_client (challenger=0x40a6d460 > <imap_challenge>, responder=0x40a77020 <imap_response>, mb=0xbfff1890, > stream=0x827a648, > trial=0xbfff1818, user=0xbfff1c30 "craig") at auth_md5.c:97 > #4 0x40a6d137 in imap_auth (stream=0x827a648, mb=0xbfff1890, > tmp=0xbfff2030 "00000001 AUTHENTICATE CRAM-MD5", usr=0xbfff1c30 "craig") > at imap4r1.c:848 > #5 0x40a6c722 in imap_open (stream=0x827a648) at imap4r1.c:636 > #6 0x40a45e7b in mail_open (stream=0x0, name=0x827a56c > "{localhost:143}INBOX", options=0) at mail.c:1012 > #7 0x40a35d2a in imap_do_open (ht=3, return_value=0x826fc04, > this_ptr=0x0, return_value_used=1, persistent=0) at php_imap.c:815 > #8 0x40a35dd5 in php_if_imap_open (ht=3, return_value=0x826fc04, > this_ptr=0x0, return_value_used=1) at php_imap.c:843 > #9 0x405c6f28 in execute () from /usr/lib/libphp_common-4.0.6.so.0 > #10 0x405c712e in execute () from /usr/lib/libphp_common-4.0.6.so.0 > #11 0x405d983c in zend_execute_scripts () from > /usr/lib/libphp_common-4.0.6.so.0 > #12 0x405e9923 in php_execute_script () from > /usr/lib/libphp_common-4.0.6.so.0 > #13 0x40434a71 in apache_php_module_main () from > /etc/httpd/extramodules/libphp4.so > #14 0x40433f1e in sapi_apache_header_handler () from > /etc/httpd/extramodules/libphp4.so > #15 0x40434203 in sapi_apache_send_headers () from > /etc/httpd/extramodules/libphp4.so > #16 0x08054ab9 in ap_invoke_handler () > #17 0x08067820 in ap_die () > #18 0x404248b0 in mod_gzip_redir1_handler () from > /etc/httpd/extramodules/mod_gzip.so > #19 0x40423700 in mod_gzip_do_command () from > /etc/httpd/extramodules/mod_gzip.so > #20 0x08054ab9 in ap_invoke_handler () > #21 0x08067820 in ap_die () > #22 0x08067bff in ap_process_request () > #23 0x0805e907 in ap_update_child_status () > #24 0x0805ebff in ap_update_child_status () > #25 0x0805ee7a in ap_update_child_status () > #26 0x0805f675 in ap_update_child_status () > #27 0x0805fcc9 in main () > #28 0x401896a0 in __libc_start_main () from /lib/libc.so.6 > > Tracing through that, and the source files, it's clear that the problem > is originating with hmac_md5 being passed a bad 5th argument, digest=0x5 > -- and that call is being made from auth_md5_client in the imap > distribution's auth_md5.c file, at line 97. > > This line is in imap-2000c/src/c-client/auth_md5.c from the imap source > tree. The hmac_md5 function is declared at the top of that file, but > defined in libsasl. Unfortunately, the imap declaration only has 4 > arguments, where the libsasl function is expecting 5. So when imap > invoked libsasl's hmac_md5, the stack is all wrong, leading to the > segfault. > > So that's the problem. > > Looking at the way the code works in each case, it looks like SASL is > expecting to receive the response buffer as 5th arg and fill it, where > IMAP is expecting SASL to return a pointer to the digest, which IMAP > then copies using sprintf() [which should probably be converted to > snprintf() -- but that's a side issue]. > > Now, the deeper problem on further inspection seems to be that IMAP is > in fact defining its own function with the same name, but in this case, > php-imap is getting linked (at runtime?) against the version of the > function in the SASL distro and not in libc-client.a from imap-devel. > There is a message warning of this possibility in the cyrus-sasl mailing > list archives: > > http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl > <http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-sasl&m > sg=403> &msg=403 > > Now, changing either of these (IMAP or SASL) would probably be harder > than just getting it to link against the correct hmac_md5 function, so I > tried playing with the linking instructions to php-imap (which are from > php-devel in the file /usr/src/php-devel/buildext and in the php-imap > SPEC file. The stuff to be linked is passed to gcc in the order: > php-imap.c /usr/lib/libc-client.a -lpam -lc -- note that nowhere in here > does it mention libsasl. > > Now I was curious, and wanted to know what was loading libsasl before > imap.so was loaded with its own hmac_md5 -- back to strace to see when > libsasl is opened. > ... > close(7) = 0 > munmap(0x4298a000, 134645) = 0 > brk(0x8104000) = 0x8104000 > brk(0x8105000) = 0x8105000 > open("/usr/lib/php/extensions/ldap.so", O_RDONLY) = 7 > read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320%\0"..., > 1024) = 1024 > fstat64(7, {st_mode=S_IFREG|0755, st_size=36708, ...}) = 0 > old_mmap(NULL, 39796, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = > 0x4298a000 > mprotect(0x42993000, 2932, PROT_NONE) = 0 > old_mmap(0x42993000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, > 7, 0x8000) = 0x42993000 > close(7) = 0 > open("/etc/ld.so.cache", O_RDONLY) = 7 > fstat64(7, {st_mode=S_IFREG|0644, st_size=134645, ...}) = 0 > old_mmap(NULL, 134645, PROT_READ, MAP_PRIVATE, 7, 0) = 0x42994000 > close(7) = 0 > open("/usr/lib/libldap.so.2", O_RDONLY) = 7 > read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@u\0\000"..., > 1024) = 1024 > fstat64(7, {st_mode=S_IFREG|0644, st_size=190484, ...}) = 0 > old_mmap(NULL, 193540, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = > 0x429b5000 > mprotect(0x429e3000, 5124, PROT_NONE) = 0 > old_mmap(0x429e3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, > 7, 0x2d000) = 0x429e3000 > close(7) = 0 > open("/usr/lib/liblber.so.2", O_RDONLY) = 7 > read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\34"..., > 1024) = 1024 > fstat64(7, {st_mode=S_IFREG|0644, st_size=40252, ...}) = 0 > old_mmap(NULL, 43308, PROT_READ|PROT_EXEC, MAP_PRIVATE, 7, 0) = > 0x429e5000 > mprotect(0x429ef000, 2348, PROT_NONE) = 0 > old_mmap(0x429ef000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, > 7, 0x9000) = 0x429ef000 > close(7) = 0 > open("/usr/lib/libsasl.so.7", O_RDONLY) = 7 > read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220$\0"..., > 1024) = 1024 > fstat64(7, {st_mode=S_IFREG|0755, st_size=213438, ...}) = 0 > brk(0x8106000) = 0x8106000 > ... > So it's being loaded by php-ldap! php-ldap is indeed linked against > libsasl (in php-ldap.spec) through libldap.so from the libldap2-devel > package. > > So being loaded into the apache process in order are: > > PHP > php-ldap > php-imap > > Those last two imports conflict, and cause the core dump when php-imap > tries to run. > > So I tried changing the /etc/php.ini configuration file, to get php-imap > to load first. This worked! > > Unfortunately, I don't have a currently working LDAP server to test > whether that has now broken CRAM-MD5 authentication from php-ldap, but I > suspect that it probably has. > > That was all rather convoluted, but I think reasonable courses of action > are probably: > > 1. Change the symbol names in either the UW-IMAP distribution or > cyrus-sasl to avoid namespace conflicts (might be hard due to getting > those package maintainer to accept fixes) > 2. Create some kind of wrapper library which isolates the namespace > conflicts if both libsasl and libimap are used simultaneously (requires > a reasonable amount of work) > 3. Change php.ini default to load imap ahead of ldap (though this might > cause further problems, and doesn't really address the basic problem). > > > If anything above needs clarification, I'd be more than happy to help > out further. Feel free to contact me by email at this address > ([EMAIL PROTECTED]) > > C Send that bug to [EMAIL PROTECTED] Cooker bugs are not handled by our usual bug-reporting system since things are often broken and the email list is used by developers to receive bug notices. MandrakeExpert serves as a filter for regular bug reports because the number of invalid bugs (user configuration errors) and requests for tech support that went into the system was making bugzilla totally unusable. A few people besides those registered at MandrakeExpert are also allowed to input bugs directly to bugzilla. For that authorization, write to [EMAIL PROTECTED], but for this particular bug report, the Cooker list is where to post it. You _can_ post to [EMAIL PROTECTED] without joining the list as long as you are willing to reply to confirmation queries. Civileme QA Team
