list mechs bug in cyrus-sasl 2.1.22 and memory leak
hyc at highlandsun.com
Tue Jan 29 16:52:01 EST 2008
Quanah Gibson-Mount wrote:
> --On Thursday, January 24, 2008 10:32 AM -0800 Quanah Gibson-Mount
> <quanah at zimbra.com> 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
> My cyrus-sasl/lib/sasl2/ directory had:
> build-mac-x86:/opt/zimbra/cyrus-sasl/lib/sasl2 root# ls
> libanonymous.2.0.22.so libcrammd18.104.22.168.so libdigestmd22.214.171.124.so
> libgssapiv126.96.36.199.so liblogin.2.0.22.so libotp.2.0.22.so
> libanonymous.2.so libcrammd5.2.so libdigestmd5.2.so
> libgssapiv2.2.so liblogin.2.so libotp.2.so
> libanonymous.la libcrammd5.la libdigestmd5.la
> libgssapiv2.la liblogin.la libotp.la
> libanonymous.so libcrammd5.so libdigestmd5.so
> libgssapiv2.so liblogin.so libotp.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:
> 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:
> Client mechlist:
> We have the following mechs:
> 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 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/
More information about the Cyrus-sasl