Description of problem: saslauthd -a rimap may fail to authenticate when using the local dovecot IMAP server for authentication. Version-Release number of selected component (if applicable): cyrus-sasl-lib-2.1.22-4 (also cyrus-sasl-2.1.23-9) How reproducible: In our environment the problem can be reproduced if one install the saslauthd and dovecot imapd on the same machine and use the local dovecot imapd for authentication (-a rimap -O localhost) Steps to Reproduce: 1. set up dovecot imapd with at least one valid user account 2. set up salsauthd, edit /etc/sysconfig/saslauthd MECH=rimap FLAGS="-O localhost" 3. # testsaslauthd -u user -p"secret" -s smtp Actual results: 0: NO "authentication failed" Expected results: 0: OK "Success." Additional info: entry in /var/log/messages saslauthd[xxx]: auth_rimap: unexpected response to auth request: saslauthd I've have examined the network traffic and identified that the authentiation failed only if the (positive) response of the imap server uses two (or more) ip packets. Whereas everything works fine if the response is sent in one packet. Having a look into the source I found the problem is in file auth_rimap.c function auth_rimap(). After the coresponding read() there is no check if there is more to read.
http://markmail.org/message/pwdowfssbie537sh has an previous talk on the issue. It seems to be about CR/LF sent by Dovecot.
As far as I can see there is no CR/LF sent by Dovecot. But the response from Dovecot is transmitted via two IP packets. See the network dump (find the response text at byte 67(0x43)): Packet 1: 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E. 0010 00 3d 40 fb 40 00 40 06 fb bd 7f 00 00 01 7f 00 .=@.@.@. ........ 0020 00 01 00 8f d0 88 09 8a 90 05 09 59 fa ad 80 18 ........ ...Y.... 0030 01 00 fe 31 00 00 01 01 08 0a 05 d7 cf 1b 05 d7 ...1.... ........ 0040 cf 17 73 61 73 6c 61 75 74 68 64 ..saslau thd Packet 2: 0000 00 00 00 00 00 00 00 00 00 00 00 00 08 00 45 00 ........ ......E. 0010 00 44 40 fc 40 00 40 06 fb b5 7f 00 00 01 7f 00 .D@.@.@. ........ 0020 00 01 00 8f d0 88 09 8a 90 0e 09 59 fa ae 80 18 ........ ...Y.... 0030 01 00 fe 38 00 00 01 01 08 0a 05 d7 cf 1b 05 d7 ...8.... ........ 0040 cf 1b 20 4f 4b 20 4c 6f 67 67 65 64 20 69 6e 2e .. OK Lo gged in. 0050 0d 0a ..
The following patch fixes the bug in my environment. --- auth_rimap.c 2010-04-20 10:49:44.000000000 +0200 +++ auth_rimap.c.new 2010-04-20 11:10:14.000000000 +0200 @@ -457,4 +457,27 @@ rc = read(s, rbuf, sizeof(rbuf)); alarm(0); + if ( rc>0 ) { + /* check if there is more to read */ + fd_set perm; + int fds, ret; + struct timeval timeout; + + FD_ZERO(&perm); + FD_SET(s, &perm); + fds = s +1; + + timeout.tv_sec = 1; + timeout.tv_usec = 0; + (void) select(fds, &perm, NULL, NULL, &timeout ); + + if ( FD_ISSET(s, &perm) ) { + ret = read(s, rbuf+rc, sizeof(rbuf)-rc); + if ( ret<0 ) { + rc = ret; + } else { + rc += ret; + } + } + } (void) close(s); /* we're done with the remote */ if (rc == -1) {
I applied the patch with success. However problem continues. [service=imap] [realm=] [mech=rimap] [reason=[ALERT] Unexpected response from remote authentication server] (In reply to comment #3) > The following patch fixes the bug in my environment. >
My previous test was with RHEL 5.4 saslauthd 2.1.22-5.el5 against Courier-IMAP server 3.0.8. Apr 21 10:36:47 2010 saslauthd[23061]: auth_rimap: unexpected response to auth request: MESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2005 Double Precision, Inc. See COPYING for distribution information. Apr 21 10:36:47 2010 saslauthd[23061]: do_auth : auth failure: [user=test] [service=smtp] [realm=] [mech=rimap] [reason=[ALERT] Unexpected response from remote authentication server] Another point: Another server with RHEL 3.4 with cyrus-sasl-2.1.15-10 is working without any error.
(In reply to comment #3) > The following patch fixes the bug in my environment. > ... The patch was for version cyrus-sasl-2.1.23-9. It fixes the bug for the situation that there are two read() calls needed to read the complete reply message from the imap server. I may provide you with a more general patch that also works if there are more than two read() calls needed.
I can try the patch for multiple reads, as well.
ok, here comes a more general patch. It reads the whole banner and authentication reply from the imap server. --- auth_rimap.c.org 2010-05-03 14:31:44.000000000 +0200 +++ auth_rimap.c 2010-05-04 13:09:21.000000000 +0200 @@ -1,2 +1,3 @@ + /* MODULE: auth_rimap */ @@ -368,4 +369,28 @@ rc = read(s, rbuf, sizeof(rbuf)); alarm(0); + if ( rc>0 ) { + /* check if there is more to read */ + fd_set perm; + int fds, ret; + struct timeval timeout; + + FD_ZERO(&perm); + FD_SET(s, &perm); + fds = s +1; + + timeout.tv_sec = 1; + timeout.tv_usec = 0; + while( select (fds, &perm, NULL, NULL, &timeout ) >0 ) { + if ( FD_ISSET(s, &perm) ) { + ret = read(s, rbuf+rc, sizeof(rbuf)-rc); + if ( ret<0 ) { + rc = ret; + break; + } else { + rc += ret; + } + } + } + } if (rc == -1) { syslog(LOG_WARNING, "auth_rimap: read (banner): %m"); @@ -457,4 +482,28 @@ rc = read(s, rbuf, sizeof(rbuf)); alarm(0); + if ( rc>0 ) { + /* check if there is more to read */ + fd_set perm; + int fds, ret; + struct timeval timeout; + + FD_ZERO(&perm); + FD_SET(s, &perm); + fds = s +1; + + timeout.tv_sec = 1; + timeout.tv_usec = 0; + while( select (fds, &perm, NULL, NULL, &timeout ) >0 ) { + if ( FD_ISSET(s, &perm) ) { + ret = read(s, rbuf+rc, sizeof(rbuf)-rc); + if ( ret<0 ) { + rc = ret; + break; + } else { + rc += ret; + } + } + } + } (void) close(s); /* we're done with the remote */ if (rc == -1) {
Dear Lutz, Patch is OK. Confirmed as working. Now, saslauthd is waiting for banner to finish, reads whole. Thank you very much.
openssh-blacklist-1.0-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/openssh-blacklist-1.0-2.fc13
openssh-blacklist-1.0-2.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/openssh-blacklist-1.0-2.fc12
openssh-blacklist-1.0-2.fc11 has been submitted as an update for Fedora 11. http://admin.fedoraproject.org/updates/openssh-blacklist-1.0-2.fc11
openssh-blacklist-1.0-2.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
openssh-blacklist-1.0-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
openssh-blacklist-1.0-2.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
(In reply to comment #17) Hm, I've found a bug in a software package of RHEL. I've debugged the code and provide you with a patch. This is my way to support Open Source Software. I will not ask any Red Hat representative to fix broken software packages. This is your business.
added to rawhide ... to be included in rhel7 ;)