Your message dated Mon, 17 Feb 2014 07:45:11 -0500
with message-id <[email protected]>
and subject line Re: Bug#402164: it isn't about ldap, just Cyrus 2.1/2.2 and
GSSAPI
has caused the Debian Bug report #402164,
regarding segfault in cyrus imapd using nss-ldap, libsasl and gssapi
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
402164: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402164
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: libsasl2-2
Version: 2.1.22.dfsg1-5
This is caused by an upgrade of libsasl2 from 2.1.19.dfsg1-0.5 to
2.1.22.dfsg1-5. I am not sure if the problem lies within sasl or
elsewhere.
cyrus-imapd2-2 2.2.13-9
libnss-ldap 251-7
libldap2 2.1.30-13+b1
slapd 2.3.29-1
libnss-ldap is configured to authenticate against slapd using GSSAPI as
a kerberos primary.
When cyrus imap runs from cyrmaster the following is reported.
Dec 8 16:25:33 mark01 cyrus/master[28994]: set maximum file descriptors
to 256/256
Dec 8 16:25:33 mark01 cyrus/master[28994]: about to
exec /usr/lib/cyrus/bin/imapd
Dec 8 16:25:33 mark01 cyrus/imap[28994]: running external
debugger: /usr/bin/gdb -batch -cd=/tmp
-x /usr/lib/cyrus/get-backtrace.gdb /usr/lib/cyrus/bin/imapd 28994
>/tmp/gdb-backtrace.cyrus.imapd.28994 <&- 2>&1 &
Dec 8 16:25:33 mark01 cyrus/imap[28994]: debugger returned exit status:
0
Dec 8 16:25:33 mark01 cyrus/imap[28994]: executed
Dec 8 16:25:33 mark01 cyrus/imap[28994]: telling master 2
Dec 8 16:25:33 mark01 cyrus/master[4240]: service imap pid 28994 in
READY state: now unavailable and in BUSY state
Dec 8 16:25:33 mark01 cyrus/master[4240]: service imap now has 0 ready
workers
Dec 8 16:25:33 mark01 cyrus/imap[28994]: accepted connection
Dec 8 16:25:33 mark01 cyrus/imap[28994]: telling master 3
Dec 8 16:25:33 mark01 cyrus/master[4240]: service imap pid 28994 in
BUSY state: now serving connection
Dec 8 16:25:33 mark01 cyrus/master[4240]: service imap now has 0 ready
workers
Dec 8 16:25:33 mark01 cyrus/master[4240]: process 28994 exited,
signaled to death by 11
Dec 8 16:25:33 mark01 cyrus/master[4240]: service imap pid 28994 in
BUSY state: terminated abnormally
Dec 8 16:25:33 mark01 cyrus/master[4240]: service imap now has 0 ready
workers
Backtrace from imapd is attached.
Removing the ldap entry from the group database in nsswitch.conf
prevents the segfault (all system groups are also available
through /etc/group).
Downgrading libsasl also resolves the problem.
Group lookups from other sources via ldap appear to be fine.
(no debugging symbols found)
Using host libthread_db library "/lib/libthread_db.so.1".
0x00002abef7fb7d32 in fsync () from /lib/libc.so.6
[Thread debugging using libthread_db enabled]
[New Thread 46999696363120 (LWP 30234)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 46999696363120 (LWP 30234)]
0x00002abefb4d2c60 in pthread_mutex_lock () from /lib/libpthread.so.0
#0 0x00002abefb4d2c60 in pthread_mutex_lock () from /lib/libpthread.so.0
#1 0x00002abefb27eb4e in ldap_pvt_thread_mutex_lock (mutex=0x1)
at
/home/mark/sources/openldap/openldap-2.1.30/libraries/libldap_r/thr_posix.c:293
#2 0x00002abefb2869b7 in ldap_pvt_sasl_mutex_lock (mutex=0x1) at cyrus.c:1081
#3 0x00002abef9fa99a4 in gssapi_client_mech_step (conn_context=0x620390,
params=0x61ff50, serverin=0x0, serverinlen=0, prompt_need=0x7fffffba8d68,
clientout=0x7fffffba8d58, clientoutlen=0x7fffffba8d64, oparams=0x61f5e0)
at gssapi.c:1365
#4 0x00002abef750f5c2 in sasl_client_step (conn=0x61ed70, serverin=0x0,
serverinlen=4216138832, prompt_need=0x1, clientout=0x7fffffba8d58,
clientoutlen=0x7fffffba8d64) at client.c:658
#5 0x00002abef750fa6e in sasl_client_start (conn=0x61ed70,
mechlist=0x2abefb15e9bb "GSSAPI", prompt_need=0x7fffffba8d68,
clientout=0x7fffffba8d58, clientoutlen=0x7fffffba8d64, mech=0x7fffffba8d78)
at client.c:606
#6 0x00002abefb285bdc in ldap_int_sasl_bind (ld=0x61e870, dn=0x0,
mechs=0x2abefb15e9bb "GSSAPI", sctrls=0x0, cctrls=0x0, flags=2,
interact=0x2abefb152fa4 <do_sasl_interact>, defaults=0x0) at cyrus.c:581
#7 0x00002abefb288e98 in ldap_sasl_interactive_bind_s (ld=0x61e870, dn=0x0,
mechs=0x2abefb15e9bb "GSSAPI", serverControls=0x0, clientControls=0x0,
flags=2, interact=0x2abefb152fa4 <do_sasl_interact>, defaults=0x0)
at sasl.c:482
#8 0x00002abefb14f56e in do_bind (ld=0x61e870, timelimit=30, dn=0x0, pw=0x0,
with_sasl=1) at ldap-nss.c:1924
#9 0x00002abefb14ef41 in do_open () at ldap-nss.c:1676
#10 0x00002abefb150412 in do_with_reconnect (
base=0x2abefb2638a1 "dc=home,dc=local", scope=2,
filter=0x2abefb26aec0 "(&(objectClass=posixGroup))", attrs=0x2abefb2644c0,
sizelimit=0, private=0x7fffffba98c8,
search_func=0x2abefb1507a3 <do_search>) at ldap-nss.c:2579
#11 0x00002abefb15150d in _nss_ldap_search (args=0x0,
filterprot=0x2abefb26aec0 "(&(objectClass=posixGroup))", sel=LM_GROUP,
user_attrs=0x0, sizelimit=0, msgid=0x7fffffba98c8, csd=0x61d0a0)
at ldap-nss.c:3221
#12 0x00002abefb1519f2 in _nss_ldap_getent_ex (args=0x0, ctx=0x2abefb264368,
result=0x2abef812edc0, buffer=0x619910 "bind", buflen=1024,
errnop=0x2abef834ce30,
filterprot=0x2abefb26aec0 "(&(objectClass=posixGroup))", sel=LM_GROUP,
user_attrs=0x0, parser=0x2abefb15454c <_nss_ldap_parse_gr>)
at ldap-nss.c:3387
#13 0x00002abefb15190a in _nss_ldap_getent (ctx=0x2abefb264368,
result=0x2abef812edc0, buffer=0x619910 "bind", buflen=1024,
errnop=0x2abef834ce30,
filterprot=0x2abefb26aec0 "(&(objectClass=posixGroup))", sel=LM_GROUP,
parser=0x2abefb15454c <_nss_ldap_parse_gr>) at ldap-nss.c:3342
#14 0x00002abefb1555bc in _nss_ldap_getgrent_r (result=0x2abef812edc0,
buffer=0x619910 "bind", buflen=1024, errnop=0x2abef834ce30)
at ldap-grp.c:1243
#15 0x00002abef7fcf58c in __nss_database_lookup () from /lib/libc.so.6
#16 0x00002abef7f8470c in getgrent_r () from /lib/libc.so.6
#17 0x00002abef7fcf22b in __nss_database_lookup () from /lib/libc.so.6
#18 0x00002abef7f84012 in getgrent () from /lib/libc.so.6
#19 0x000000000044f945 in lock_sigalrm_handler ()
#20 0x000000000043a8cb in mboxlist_findall ()
#21 0x00000000004157b2 in idle_update ()
#22 0x00002abef7515b2f in do_authorization (s_conn=0x60fef0) at server.c:1185
#23 0x00002abef751605a in sasl_server_step (conn=0x60fef0,
clientin=0x7fffffbaa310 "`?\006\t*\206H\206÷\022\001\002\002\002\001\004",
clientinlen=<value optimized out>, serverout=0x7fffffbaf870,
serveroutlen=<value optimized out>) at server.c:1442
#24 0x000000000043c508 in mboxlist_findall ()
#25 0x000000000041608c in idle_update ()
#26 0x000000000041969f in idle_update ()
#27 0x0000000000419c44 in idle_update ()
#28 0x00000000004072d1 in ?? ()
#29 0x00002abef7f114ca in __libc_start_main () from /lib/libc.so.6
#30 0x0000000000406a7a in ?? ()
#31 0x00007fffffbb2298 in ?? ()
#32 0x0000000000000000 in ?? ()
--- End Message ---
--- Begin Message ---
On Sat, Feb 08, 2014 at 05:37:02PM -0500, Roberto C. Sánchez wrote:
> On Sat, Feb 08, 2014 at 02:19:25PM -0800, Russ Allbery wrote:
> >
> > This is the sort of bug where I'm dubious there's much benefit to holding
> > it open unless someone can reproduce it with the packages currently in the
> > archive, as unsatisfying as that approach is. The last report was six
> > years ago, and it was a segfault in Cyrus imapd. If Cyrus impad were
> > regularly segfaulting for lots of users, there would be a lot more bug
> > reports, so we know it's some sort of edge case. If that edge case isn't
> > still happening, I'm not sure there's any real action that you can take at
> > this point.
> >
> Russ,
>
> Thanks very much for the detailed analysis. I feared that such might be
> the case, but I have followed up directly with Dennis (who provided the
> GDB backtrace and opined that the problem might with Kerberos) to see if
> he is still experiencing the same behavior.
>
Based on the lack of a follow-up, I am closing this bug. If additional
information relevant to this issue (i.e., as described by Russ above)
becomes available, feel free to re-open this report.
Regards,
-Roberto
--
Roberto C. Sánchez
http://people.connexer.com/~roberto
http://www.connexer.com
signature.asc
Description: Digital signature
--- End Message ---
