openldap client GSSAPI authentication segfaults in fbsd8stable i386

[Reko Turja]

>> I have a problem: ldapsearch results in "Segmentation fault" under
>> openldap-2.4.23 with cyrus-sasl-2.1.23
>>
>> A thread for similar issues was started by George Mamalakis back in
>> february:
>> http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html
>> but I find no solution / conclusion from this thread, hence I post 
>> here...
>>
>> I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with
>> freebsd-update, and ports updated with "portsnap fetch update".
>>
>> Kerberos installed from packages, configured, and seems to work OK.

I had similar issue with 8-RELEASE and cyrus-sasl2 with 
cyrus-saslauthd linked against system kerberos.

(uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat 
Jun 12 00:39:22 EEST 2010 
root at xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW  i386)

The problem manifested itself with pretty much the same backtrace when 
using cyradm tool for administering cyrus mailboxes and due time 
constraints I solved my issue by removing all the gssapi plugin libs 
from /usr/local/lib/sasl2, so my solution isn't really applicable in 
your case.

my /etc/hosts file for the server in question contains only localhost 
entry + entry for one IP so George's solution didnt help with my 
problem.

>> /var/log/messages has:
>> slapd[1146]: OTP unavailable because can't read/write key database
>> /etc/opiekeys: Permission denied
>> kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core 
>> dumped)
>>
>> The first message is from the LDAP server. Even if it has some
>> problem, it should not lead the client to segfault.
>
> I agree.
>
> If I was to build a test box from scratch, can you tell me how to 
> set up
> all the necessary software/etc. to mimic your environment so that I
> could try to reproduce this?  Reviewing the source isn't enough, I'd
> have to actually build a debug version of libgssapi to track it 
> down.

> Alternatively I can try to step you through how to debug this using 
> gdb,
> but again, lack of debugging symbols makes this annoying.

I'd say that based on present evidence there is something broken in 
gssapi/sasl interaction, but due my need of getting the server 
functional quickly I didn't dig much further in the issue myself, 
although I really don't know how to enable generating debugging 
symbols for ports either - Which was another reason for not digging 
deeper in the problem.

I wonder if using dovecot-sasl would work with ldap and if it has the 
same issue as cyrus-sasl - athough it doesn't seem to be available as 
separate port.

-Reko