tags 527246 + pending thanks On Fri, 2009-05-08 at 09:40 +0200, Jonathan Quick wrote: > > What kind of information do you have in LDAP? Do you define services > > there? Do they show up correctly with getent services? > > Ah, I've found exactly what is triggering it. When I run 'getent > services' it also segfaults, but only after listing some of the > services I have defined in the LDAP. Comparison with the output from > libnss-ldap on another machine reveals that the problem occurs when > the CN entry is in uppercase, but the corresponding DN is in lowercase > eg. > > dn="cn=sssin,ou=Services,dc=hartrao,dc=ac,dc=za" > cn="SSSIN"
Thanks very much for finding this. With this I've been able to reproduce the bug and narrow it down. There were actually two bugs. The first problem was that the server component got confused as to which entries needed to be written and which didn't (some comparisons were case-sensitive and others case-insensitive). This resulted in more entries being written than expected which caused the receiving end to mix up the protocol and expect very large strings. The second problem was that the NSS module signalled to Glibc that it didn't have enough memory to store the information (for the very long string) and kept asking for more memory. At a certain point Glibc passes NULL as a memory buffer at which point things break. This last part caused the segmentation fault. IMO a segmentation fault is always a bug. > Interestingly enough, the libnss-ldap implementation returns > > sssin 5000/tcp SSSIN > > quite happily. This is also what nss-ldapd will return now. Thanks for finding this bug. I don't know if I will be able to propagate this fix to lenny though. -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong --
signature.asc
Description: This is a digitally signed message part
