Cyrus IMAPd 2.2.3 Released

[Ken Murchison]

dimon at intellinetinc.com wrote:

> Quoting Igor Brezac <igor at ipass.net>:
> 
> 
>>On Wed, 28 Jan 2004 dimon at intellinetinc.com wrote:
>>
>>
>>>>>Jan 16 06:59:18 synodon imap[58231]: size read failed
>>>>>Jan 16 06:59:18 synodon imap[58231]: badlogin: [68.147.210.233]
>>
>>plaintext
>>
>>>>>dennis.rendflesh SASL(-1): generic failure: checkpass failed
>>>>>Jan 16 06:59:24 synodon /kernel: pid 44231 (saslauthd), uid 0: exited
>>
>>on
>>
>>>>>signal 11 (core dumped)
>>>
>>>>Hmm, I not sure what that is.  Can you give us backtrace and your
>>>>saslauthd startup cmd?
>>>>
>>>
>>>saslauthd -a pam (with pam_pgsql) still gives me that problem :-(
>>>
>>>Today I tried to use gdb on saslauthd and that's what I've got:
>>>
>>>Program received signal SIGSEGV, Segmentation fault.
>>>0x28104942 in vfprintf () from /usr/lib/libc.so.4
>>>
>>>I don't know if that will give you any clue
>>>
>>>Any help will be greatli appreciated!
>>
>>This does not help.  Run gdb against the saslauthd core file and type bt.
>>
> 
> This is output of gdb on one of my servers:
> 
> [root at demo saslauthd]# gdb saslauthd saslauthd.core
> GNU gdb 4.18 (FreeBSD)
> Copyright 1998 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 "i386-unknown-freebsd"...(no debugging symbols 
> found)...
> Core was generated by `saslauthd'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libcrypt.so.2...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/lib/libpam.so.1...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/libc.so.4...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/pam_pgsql.so...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/local/lib/libpq.so.3...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/lib/libmd.so.2...(no debugging symbols found)...done.
> Reading symbols from /usr/local/lib/libintl.so.5...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/local/lib/libssl.so.3...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/local/lib/libcrypto.so.3...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/lib/pam_skey.so...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/libskey.so.2...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/lib/pam_unix.so...(no debugging symbols found)...done.
> Reading symbols from /usr/lib/libutil.so.3...(no debugging symbols 
> found)...done.
> Reading symbols from /usr/libexec/ld-elf.so.1...(no debugging symbols 
> found)...done.
> #0  0x28104942 in vfprintf () from /usr/lib/libc.so.4
> (gdb) bt
> #0  0x28104942 in vfprintf () from /usr/lib/libc.so.4
> #1  0x280eae92 in vsyslog () from /usr/lib/libc.so.4
> #2  0x280eabe5 in syslog () from /usr/lib/libc.so.4
> #3  0x2812e102 in pam_sm_acct_mgmt () from /usr/lib/pam_pgsql.so
> #4  0x2808c271 in pam_getenvlist () from /usr/lib/libpam.so.1
> #5  0x2808c51d in _pam_dispatch () from /usr/lib/libpam.so.1
> #6  0x2808b56c in pam_acct_mgmt () from /usr/lib/libpam.so.1
> #7  0x8049ad0 in auth_pam ()
> #8  0x804c7ac in do_auth ()
> #9  0x804bee1 in do_request ()
> #10 0x804bb39 in ipc_loop ()
> #11 0x804c743 in main ()
> #12 0x804972e in _start ()
> (gdb) quit

Something in the pam_pgsql module is causing vfprintf() to crash.  Does 
this happen for every authentication, or just once in a while. If the 
latter, try running saslauthd -n 0 (zero), this might hide any memory 
leaks in PAM of the pgsql module.

Unless you actually need PAM for some reason, I'd suggest using the SQL 
auxprop plugin included in SASL (which supports PgSQL).  It will 
elimiate any PAM issues and allow you to use non-plaintext mechanisms as 
well.

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp