Quanah Gibson-Mount wrote:
--On Thursday, January 24, 2008 10:32 AM -0800 Quanah Gibson-Mount
<quanah@xxxxxxxxxx> wrote:
The problem does not occur with the Mac system sasl library. It only
occurs with stock builds of cyrus-sasl. I.e., Apple's fixed the issue
apparently, but their source is very heavily modified, I've just begun
looking into it. They also are using the rather old 2.1.18, and I need
2.1.22. ;) The same issues with a stock 2.1.18 build as well.
This appears to be a problem in the way that the plugins are loaded with
add_plugin.
My cyrus-sasl/lib/sasl2/ directory had:
build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# ls
libanonymous.2.0.22.so libcrammd5.2.0.22.so libdigestmd5.2.0.22.so
libgssapiv2.2.0.22.so liblogin.2.0.22.so libotp.2.0.22.so
libplain.2.0.22.so
libanonymous.2.so libcrammd5.2.so libdigestmd5.2.so
libgssapiv2.2.so liblogin.2.so libotp.2.so
libplain.2.so
libanonymous.la libcrammd5.la libdigestmd5.la
libgssapiv2.la liblogin.la libotp.la
libplain.la
libanonymous.so libcrammd5.so libdigestmd5.so
libgssapiv2.so liblogin.so libotp.so
libplain.so
So I then did:
build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# rm libplain.so
build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# rm libplain.2.so
Then when I run the script, I get:
[EXTERNAL,ANONYMOUS,ANONYMOUS,ANONYMOUS,CRAM-MD5,CRAM-MD5,CRAM-MD5,DIGEST-MD
5,DIGEST-MD5,DIGEST-MD5,GSSAPI,GSSAPI,GSSAPI,LOGIN,LOGIN,LOGIN,OTP,OTP,OTP,PLAIN]
See how plain is only listed *once* now.
So apparently SASL is treating every *.so file as a plugin when on a Mac,
rather than ignoring the symlinks.
The SASL code never checks to see if a file is a symlink or not. (Nor should
it, since you might legitimately symlink a plugin from some other location
into the default plugin directory.) All it does is look for a ".so" or ".la"
suffix, and it ignores anything else. This works on most platforms because for
versioned files, they stick the version *after* the .so suffix. E.g. you would
have libplain.so and libplain.so.2, libplain.so.2.0.22.
Why they've messed with the order of name components on MacOS is beyond me. Is
that the way all other shared libraries are named as well, or is this just a
broken libtool installing things with the wrong names?
In fact, if I remove all the symlinks, I get:
Testing sasl_listmech()...
Client sasl_client_add_plugin: Added mech EXTERNAL
Client sasl_client_add_plugin: Added mech ANONYMOUS
Client sasl_client_add_plugin: Added mech CRAM-MD5
Client sasl_client_add_plugin: Added mech DIGEST-MD5
Client sasl_client_add_plugin: Added mech GSSAPI
Client sasl_client_add_plugin: Added mech LOGIN
Client sasl_client_add_plugin: Added mech OTP
Client sasl_client_add_plugin: Added mech PLAIN
Global mechanisms list:
[EXTERNAL,ANONYMOUS,CRAM-MD5,DIGEST-MD5,GSSAPI,LOGIN,OTP,PLAIN]
Client mechlist:
[PLAIN,OTP,LOGIN,GSSAPI,DIGEST-MD5,CRAM-MD5,ANONYMOUS,EXTERNAL]
We have the following mechs:
[PLAIN,LOGIN,GSSAPI,DIGEST-MD5,CRAM-MD5,ANONYMOUS,EXTERNAL]
All memory accounted for!
Testing sasl_listmech()... ok
All tests seemed to go ok (i.e. we didn't crash)
Yeah, no memory leak. So this is definitely a problem of determining
symlink vs actual file in the SASL code for macintosh.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
