OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: Cyrus SASL issue (solved) when upgrading to 2.3

From: Luc Pardon (lucpskopos.be)
Date: Thu Feb 02 2006 - 09:58:37 CST


Patrick Ben Koetter wrote:
> * Luc Pardon <lucpskopos.be>:
>
>>
>> The OS is Redhat Linux and the Cyrus versions are 2.0.16 for imapd
>>and 1.5.24 for sasl (and no, this is not a museum's mail system). The
>>cyrus-sasl-gssapi module is installed.
>>
>> Cyrus SASL uses pwcheck_method:sasldb, and postfix has
>>lmtp_sasl_password_maps = hash:/etc/postfix/lmtp_sasl_pass in main.cf.
>
>
> Cyrus SASL doesn't know any pwcheck_method called sasldb. What you experienced
> before you upgraded was the fallback behaviour of Cyrus SASL, where it would
> fall back to sasldb if the given pwcheck_method would not work.
>
> Set this in smtpd.conf to configure Cyrus-SASL.2.x correctly:
>
> pwcheck_method: auxprop
> auxprop_plugin: sasldb
>

     OK for Cyrus-SASL.2.x, but I'm using Cyrus-SASL.1.5.24 which did
have such a pwcheck_method (as mentioned in Postfix SASL_README).
However, in both cases it ends up using the Cyrus SASL password file, as
intended.

>> The SASL_README says that this message happens with plaintext auth,
>>but I already had smtp_sasl_security_options = noanonymous (from way
>>before the upgrade).
>
>
> In your case, using the lmtp-client, that would have to be:
>
> lmtp_sasl_security_options = noanonymous
>

    Yes indeed, typo, sorry. I pasted from SASL_README where it explains
the error message in the server section instead of main.cf. It's lmtp_
in main.cf allright. Not that it matters, I think, since it ends up
using cram-md5 so plaintext allowed or not would be irelevant. Maybe.

>
>
>> With -v added to lmtp in master.cf, the logs seemed to indicate that
>>the Postfix lmtp client did manage to talk to Cyrus. Cyrus announced
>>"250-AUTH GSSAPI LOGIN DIGEST-MD5 CRAM-MD5 PLAIN EXTERNAL" but the
>>Postfix lmtpd did not seem to know what to pick. In any case it didn't
>
> ^^^^^
> lmtp-client...
>

    Typo again, but this time not even wrong cut&paste, just plain me ...

>>
>> 1. Could it be that Postfix's 2.3 new smtp/lmtp client is selecting
>>the auth mechanism in a different way than 2.2, or even that it does not
>>know any mechanisms without the help of lmtp_sasl_mechanism_filter ?
>
>
> The Cyrus-SASL.2.x libsasl library chooses which mechanism should be used, not
> Postfix. Postfix can only filter mechanisms it got offered in order to submit
> only a limited subset of offered mechanisms to libsasl - that's how Postfix
> keeps libsasl from choosing mechanisms it can't handle e.g. because it wasn't
> configured to do so.

     OK, I see. Interesting.

    So it must be the way that Postfix calls sasl_client_new and/or
sasl_client_start that has changed between PF 2.2 and 2.3, resulting in
a different mechanism being choosen.

    I had a look at the source code and the logs. It looks like it hangs
75s in smtp_sasl_authenticate(). While in there, the log shows a
callback to xsasl_cyrus_get_user but not to xsasl_cyrus_get_password.

    Comparing the PF 2.2 and 2.3 sources, I see only one obvious (?)
difference. In the new code, in src/xsasl/xsasl_cyrus_client.c,
  function xsasl_cyrus_client_set_security(), line 385-385 it reads:

> sec_props.max_ssf = 0; /* don't allow real SASL
> * security layer */

    The old sources (src/lmtp/lmtp_sasl_glue.c) set max_ssf to 1.

    I've done some reading at
http://asg.web.cmu.edu/cyrus/download/sasl/programming.html and that
_might_ explain why libsasl selects a different mechanism.

    Thoughts ?

    Luc