SASL2 plugin problem
Xu, Qiang (FXSGSC)
Qiang.Xu at fujixerox.com
Fri Apr 3 02:43:38 EDT 2009
> -----Original Message-----
> From: Howard Chu [mailto:hyc at highlandsun.com]
> Sent: Friday, April 03, 2009 1:07 PM
> To: Xu, Qiang (FXSGSC)
> Cc: Henry B. Hotz; cyrus-sasl at lists.andrew.cmu.edu
> Subject: Re: SASL2 plugin problem
> Don't use MozLDAP, it's obsolete. At this point it's total
> abandonware, it's not even present in any current Mozilla
> builds. (And yes, I build a full Mozilla source tree on a
> pretty frequent basis. I've also submitted a patch to build
> Mozilla with OpenLDAP's libldap, since Mozilla has abandoned
> the MozLDAP code.)
For SASL LDAP binding, I see that OpenLDAP + SASL is the most used combination. Yet, from my googling, there are some successful examples of use MozLDAP with SASL.
> Given that both MozLDAP and OpenLDAP use the same SASL
> library, and OpenLDAP works, how can you deduce that the
> problem is in the SASL library?
Hmmm, you are right about this. But I also have my reasons. See below.
> > The caller seems innocent:
> > ========================================
> > <apManager> (Tue Mar 31 2009
> > INFO>> Value of hostname sesswin2003:389
> Fix that. MozLDAP isn't parsing it correctly; just use the hostname.
> The C API spec says that this is allowed to be in host:port
> form, and the LDAP library is supposed to recognize that and
> parse it appropriately when this form is passed in. MozLDAP
> doesn't parse it though, it uses it verbatim. When it hands
> this host:port form to SASL, which expects hostname and
> portnumber as two separate parameters, things fail.
> The Mozilla LDAP codebase deviates from (or simply fails to
> implement) the LDAP specs in lots of ways. I guess here's a
> case where it failed to follow the SASL API as well.
But how to explain in case of simple LDAP binding, the format "host:port" can be handled (the format "host:port" can be recognized and separated for DNS request)? In both simple binding and sasl binding, they are using the same function, with the same paremeter passed in. Thus, I can't help thinking something is not quite right with SASL libraries. But what you said is also reasonable, SASL works well with OpenLDAP, so it can hardly be faulted.
A side note: In my printer, I found SASL library depends on OpenLDAP libraries, while in my case, it is supposed to interact with MozLDAP library:
MBC107:/usr/lib <190> ldd libsasl2.so
linux-gate.so.1 => (0xffffe000)
libresolv.so.2 => /lib/libresolv.so.2 (0xb7f38000)
libssl.so.0.9.7 => /lib/libssl.so.0.9.7 (0xb7f06000)
libdl.so.2 => /lib/libdl.so.2 (0xb7f02000)
libmysqlclient.so.15 => /lib/libmysqlclient.so.15 (0xb7ea4000)
libz.so.1 => /usr/lib/libz.so.1 (0xb7e92000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7e64000)
libnsl.so.1 => /lib/libnsl.so.1 (0xb7e50000)
libm.so.6 => /lib/libm.so.6 (0xb7e2c000)
libpq.so.4 => /usr/lib/libpq.so.4 (0xb7e0d000)
libldap-2.3.so.0 => /lib/libldap-2.3.so.0 (0xb7dd9000)
libc.so.6 => /lib/libc.so.6 (0xb7cc8000)
libcrypto.so.0.9.7 => /lib/libcrypto.so.0.9.7 (0xb7bc0000)
libkrb5.so.3 => /lib/libkrb5.so.3 (0xb7b4b000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7b38000)
liblber-2.3.so.0 => /lib/liblber-2.3.so.0 (0xb7b2b000)
libk5crypto.so.3 => /lib/libk5crypto.so.3 (0xb7b06000)
libcom_err.so.3 => /lib/libcom_err.so.3 (0xb7b02000)
libkrb5support.so.0 => /usr/lib/libkrb5support.so.0 (0xb7afe000)
In the list, libldap-2.3.so and liblber-2.3.so are components of OpenLDAP. I don't know this has any effect on the DNS error.
> If you want code that actually works and adheres to
> standards, stick with OpenLDAP.
But our printers are using MozLDAP SDK, not OpenLDAP. Alas!
More information about the Cyrus-sasl