list mechs bug in cyrus-sasl 2.1.22 and memory leak

[Howard Chu]

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
> 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/