Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 392761 - dev-libs/cyrus-sasl-2.1.25 saslauthd PLAIN broken auth mechanism
Summary: dev-libs/cyrus-sasl-2.1.25 saslauthd PLAIN broken auth mechanism
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Net-Mail Packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-01 23:24 UTC by Guillaume Castagnino
Modified: 2012-01-12 22:51 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Guillaume Castagnino 2011-12-01 23:24:54 UTC
It seems that cyrus-sasl-2.1.25 is quite broken. Googling for it give tons of different issues.

The issue I found is with PLAIN (which I usually use) authentication mechanism.
After upgrading cyrus-sasl to 2.1.25 (and recompiling cyrus-imapd and openldap: needed because of library versionning issues: /usr/lib64/libsasl2.so.2: no version information available), PLAIN is no more functional :


BEFORE:

#  imtest -a casta@xwing.info localhost 
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=PLAIN SASL-IR] xwing.info Cyrus IMAP v2.4.12 server ready
Please enter your password: 
C: A01 AUTHENTICATE PLAIN __MY_BASE64_HASH__==
S: A01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY X-NETSCAPE LOGINDISABLED COMPRESS=DEFLATE IDLE] Success (no protection)
Authenticated.
Security strength factor: 0
^CC: Q01 LOGOUT
Connection closed.



AFTER:

# imtest -a casta@xwing.info localhost
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=PLAIN SASL-IR] xwing.info Cyrus IMAP v2.4.12 server ready
Please enter your password: 
C: A01 AUTHENTICATE PLAIN __MY_BASE64_HASH__==
S: A01 NO no mechanism available
Authentication failed. generic failure
Security strength factor: 0

And in my logs I get this :
imaps[32134]: badlogin: 168.44.9.109.rev.sfr.net [109.9.44.168] PLAIN [SASL(-4): no mechanism available: ]



But the cleartext auth login continue to work:
#  imtest -a casta@xwing.info localhost -m login
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=PLAIN SASL-IR] xwing.info Cyrus IMAP v2.4.12 server ready
Please enter your password: 
C: L01 LOGIN casta@xwing.info {10}
S: + go ahead
C: <omitted>
S: L01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY X-NETSCAPE LOGINDISABLED COMPRESS=DEFLATE IDLE] User logged in SESSIONID=<xwing.info-24639-1322779092-1>
Authenticated.
Security strength factor: 0
^CC: Q01 LOGOUT


Downgrading to 2.1.23-r6 fixes this, and PLAIN auth mech works again. Quickly looking, it seems that CRAM-MD5 suffers of the same issue : "no mechanism available" error.
So IMHO, dev-libs/cyrus-sasl-2.1.25 should be masked in tree until such big issues are sorted upstream. It's quite unusable as-is.

May be related to such issue: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3173 ?
Comment 1 Rolf S. Arvidson 2011-12-02 00:38:12 UTC
I can confirm similar behavior:
With cyrus-sasl-2.1.25, mutt times out with:

  mutt: /usr/lib64/libsasl2.so.2: no version information available

This issue does not exist with cyrus-sasl-2.1.23-r6 installed with

dev-libs/cyrus-sasl-2.1.23-r6 USE="crypt% gdbm java pam ssl-authdaemond -berkdb -kerberos -mysql -ntlm_unsupported_patch% -openldap -postgres -sample -srp -urandom (-ldapdb%) (-sqlite%) (-static-libs%)"
Comment 2 Guillaume Castagnino 2011-12-02 07:06:33 UTC
(In reply to comment #1)
> I can confirm similar behavior:
> With cyrus-sasl-2.1.25, mutt times out with:
> 
>   mutt: /usr/lib64/libsasl2.so.2: no version information available
> 
> This issue does not exist with cyrus-sasl-2.1.23-r6 installed with

This seems not the same issue: this vanishes by recompiling the software that link on libsasl2.
What I'm talking here is is more specifically SASL auth mechanisms used by cyrus-imap that becomes broken ("no mechanism available" error) with this cyrus-sasl version.
Ubuntu has the same: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/875440
Comment 3 Rolf S. Arvidson 2011-12-02 13:05:50 UTC
(In reply to comment #2)
> (In reply to comment #1)
> This seems not the same issue: this vanishes by recompiling the software that
> link on libsasl2.
> What I'm talking here is is more specifically SASL auth mechanisms used by
> cyrus-imap that becomes broken ("no mechanism available" error) with this
> cyrus-sasl version.
> Ubuntu has the same:
> https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/875440

You're correct, my apologies.
Comment 4 Julian Cromarty 2011-12-06 13:32:43 UTC
I'm having the same problems, again with cyrus-sasl-2.1.25. I noticed it when I found it when trying to add the enlightenment overlay which uses subversion which in turn uses SASL to authenticate (at least it seems to for svn://overlays.gentoo.org). As mentioned above, recompiling subversion removed the version information error, but the main error remains.
Comment 5 Eray Aslan gentoo-dev 2011-12-07 12:51:57 UTC
I can't reproduce this with cyrus-sasl-2.1.25:

# imtest -a eras localhost
S: * OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE STARTTLS AUTH=PLAIN AUTH=LOGIN SASL-IR] london0.caf.com.tr Cyrus IMAP v2.4.12 server ready
Please enter your password: 
C: A01 AUTHENTICATE PLAIN __MY_BASE64_HASH__==
S: A01 OK [CAPABILITY IMAP4rev1 LITERAL+ ID ENABLE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY CATENATE CONDSTORE ESEARCH SORT SORT=MODSEQ SORT=DISPLAY THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE LIST-EXTENDED WITHIN QRESYNC SCAN XLIST URLAUTH URLAUTH=BINARY X-NETSCAPE LOGINDISABLED COMPRESS=DEFLATE IDLE] Success (no protection)
Authenticated.
Security strength factor: 0
a logout
* BYE LOGOUT received
a OK Completed
Connection closed.


Does it work if you change your backend from ldap to something else?  Does testsaslauthd work correctly?  Also, if any of you is using postfix, saslfinger (google for it) output might help.
Comment 6 Guillaume Castagnino 2011-12-08 13:55:12 UTC
testsaslauthd result is fine:
testsaslauthd -f /var/spool/postfix/var/lib/sasl2/mux -u casta@xwing.info -p XXXXXXXXX
0: OK "Success."

On postfix side, saslfinger reports nothing special. But same error using SASL PLAIN authentication on postfix:
5.7.8 Error: authentication failed: no mechanism available


I cannot switch to other backend than ldap currently: need to much offline time, and this server is my production homeserver with all family and friends mailboxes...
Comment 7 Reuben Farrelly 2011-12-20 03:04:16 UTC
+1 here.  I am using cyrus-sasl to authenticate SMTP with Postfix using [PLAIN and LOGIN] auth methods, and it is completely broken in 2.1.25 (but works fine in 2.1.23-r6).  I also get the "no mechanism available".

Postfix debugging shows:

"SASL authentication debug: could not find auxprop plugin"

I have no database set up or defined as my saslauth is using PAM authentication.
Comment 8 mishikal 2012-01-11 21:24:46 UTC
See https://bugzilla.cyrusimap.org/show_bug.cgi?id=3590 for a patch
Comment 9 Guillaume Castagnino 2012-01-12 00:26:06 UTC
GREAT !!!

This patch indeed fixes the issue !
Comment 10 Eray Aslan gentoo-dev 2012-01-12 07:35:10 UTC
In the tree.  Thanks for the report.

+*cyrus-sasl-2.1.25-r1 (12 Jan 2012)
+
+  12 Jan 2012; Eray Aslan <eras@gentoo.org> +cyrus-sasl-2.1.25-r1.ebuild,
+  +files/cyrus-sasl-2.1.25-auxprop.patch:
+  fix PLAIN and LOGIN with no auxprop - bug #392761
+