[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: GSSAPI (SASL) + LDAP
Daniel Savard wrote:
> Le vendredi 10 fÃvrier 2012 Ã 15:45 -0800, Quanah Gibson-Mount a Ãcrit :
>> --On Friday, February 10, 2012 6:21 PM -0500 Daniel Savard
>> <dsavard@cids.ca> wrote:
>>
>>> For the records, I did upgrade to OpenLDAP 2.4.28, latest stuff. It
>>> doesn't solve anything.
>>>
>>
>> If the issue is what version of Kerberos sasl is linked against, upgrading
>> OpenLDAP isn't going to help you at all. I suggest you run your ldapsearch
>> command under gdb and get a backtrace of where the segfault is occurring.
>
>
> Very strange findings. First, I decided to try the ldapwhoami from
> another client and here what I got:
>
> $ ldapwhoami
> SASL/GSSAPI authentication started
> SASL username: dsavard@CIDS.CA
> SASL SSF: 56
> SASL data security layer installed.
> dn:cn=daniel savard,dc=cids,dc=ca
> $ echo $?
> 0
> $
>
> Then I did ran with gdb the ldapwhoami on the previous client and here
> is what I got:
>
> (gdb) run
> Starting program: /usr/bin/ldapwhoami
> [Thread debugging using libthread_db enabled]
> SASL/GSSAPI authentication started
> SASL username: dsavard@CIDS.CA
> SASL SSF: 56
> SASL data security layer installed.
> dn:cn=daniel savard,dc=cids,dc=ca
>
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7e82231 in free () from /lib/libc.so.6
> (gdb)
>
>
> glibc is same version everywhere, as openldap, openssl, sasl and
> mit-krb5. So far, the only difference I see is the architecture, the
> working one is 64-bits while others are 32-bits.
>
> I did the same with a ldapsearch which is working but SIGSEGV on the
> 32-bits clients.
>
> Anything else I can do to identify the problem and fix it?
>
> THX
>
>
Hi,
I had some weirdness associated with client programs under x86
architecture that I experienced a while back. The version was 2.4.24
and above (IIRC). I use GSSAPI via SASL for authentication and I'm also
using Gentoo with both 32/64 builds of OpenLDAP. What I found was that
not building Cyrus-SASL with PostgreSQL support caused the problem to go
away. In my case the problem was an issue which occurred when freeing
memory after client programs like ldapwhoami terminated (either
successfully or not).
Tully Gray.