--On Tuesday, January 10, 2012 1:10 PM -0800 Quanah Gibson-Mount
<quanah@xxxxxxxxxx> wrote:
I would also note, that with cyrus-sasl 2.1.23, where things *work* just
fine, I get the same result:
root@zqa-061:/opt/zimbra/cyrus-sasl-2.1.23.3z/sbin# ./pluginviewer -a
Installed auxprop mechanisms are:
(null)
It seems to me like the lack of auxprop mechanisms completely breaks
Cyrus-SASL in 2.1.25, where as in 2.1.23, other plugins would continue to
work.
Hi Dan,
In summary:
The reworking of _sasl_auxprop_lookup in 2.1.25 is completely broken. By
creating a return status that defaults to SASL_NOMECH, if someone builds
cyrus-sasl with no auxprop mechanisms, all authentications fail because
this one function cannot load the auxprop modules, since they don't exist.
This is even somewhat noted in one comment in the function itself:
/* TODO: Ideally, each auxprop plugin should be marked if its
failure
should be ignored or treated as a fatal error of the whole
lookup. */
I was able to get 2.1.25 to correctly work when there are no auxprop
plugins with the following patch:
--- auxprop.c.orig 2012-01-11 12:34:03.948477379 -0800
+++ auxprop.c 2012-01-11 12:34:45.878474663 -0800
@@ -917,7 +917,10 @@
(sasl_callback_ft *)&getopt,
&context) == SASL_OK) {
ret = getopt(context, NULL, "auxprop_plugin", &plist, NULL);
- if(ret != SASL_OK) plist = NULL;
+ if(ret != SASL_OK) {
+ plist = NULL;
+ result = SASL_OK;
+ }
}
if(!plist) {
I.e., if we are not able to load the aux prop plugins when we call getopt,
set plist to NULL and set the result to SASL_OK.
This is probably not the best solution in the world, as I imagine there may
be other reasons why the getopt call here may fail, but it does return the
behavior of the function to matching 2.1.23, and allows builds w/o auxprop
to function correctly.
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration
