Postfix SMTP auth doesn't work with cyrus-sasl 2.1.25

[Alexey Melnikov]

On 11/01/2012 20:58, Quanah Gibson-Mount wrote:
> --On Tuesday, January 10, 2012 1:10 PM -0800 Quanah Gibson-Mount 
> <quanah at zimbra.com> wrote:
>
>> I would also note, that with cyrus-sasl 2.1.23, where things *work* just
>> fine, I get the same result:
>>
>> root at 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.

That might fix your problem, but I don't believe this is the correct 
fix, as it might break other SASL mechanisms.

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