Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 57522 - cyrus-sasl-1.5.24-23 breaks php-imap with GSSAPI
cyrus-sasl-1.5.24-23 breaks php-imap with GSSAPI
Product: Red Hat Linux
Classification: Retired
Component: cyrus-sasl (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Nalin Dahyabhai
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2001-12-14 15:14 EST by Julio Sanchez Fernandez
Modified: 2007-04-18 12:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-18 14:34:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Packet capture of broken GSSAPI authentication (1.82 KB, application/octet-stream)
2001-12-14 15:16 EST, Julio Sanchez Fernandez
no flags Details

  None (edit)
Description Julio Sanchez Fernandez 2001-12-14 15:14:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en]C-STL/0.3  (WinNT; U)

Description of problem:
The new cyrus-sasl packages have some glitch that makes php-imap build incorrect GSSAPI authentication and, so fails to connect to the IMAP server. 
Going back to cyrus-sasl-1.5.24-20 restores the functionality.

I see it with cyrus-imapd 2.0.15 and horde 1.2.7 and imp 2.2.7

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Attempt to login in IMP when the IMAP server is in a Kerberos environment and, thus, announces AUTH=GSSAPI in CAPABILITIES

Actual Results:  IMP closes the connection because of invalid login or "timeout" (sic) and shows the login form again

Expected Results:  IMP should have shown the INBOX, etc.

Additional info:

I have a ethereal (pcap) capture that I will upload showing the (broken) dialog between php-imap and cyrus-imapd.

Since the last package was released for security reasons, it does not work and the workaround is going back to unsafe versions, I will tag this with 
Security severity.
Comment 1 Julio Sanchez Fernandez 2001-12-14 15:16:42 EST
Created attachment 40672 [details]
Packet capture of broken GSSAPI authentication
Comment 2 Julio Sanchez Fernandez 2001-12-17 04:11:13 EST
Hold it, downgrading does not fix it reliably, so I may be seeing ghosts.

I have a problem but I don't really know where is it coming from.
Comment 3 Nalin Dahyabhai 2002-01-18 13:07:47 EST
Do you have the cyrus-sasl-gssapi package installed on the system using PHP?  If
so, try removing it.
Comment 4 Julio Sanchez Fernandez 2002-05-30 14:46:55 EDT
I had this in the back burner and had had not time to investigate it, since
it was happening in a non-critical host.  It hit me hard this morning after
I upgraded a critical host to RH 7.2 yesterday.

So I have spent today reading code.  Your suggestion about removing
cyrus-sasl-gssapi is right on the mark:  after you delete it, it starts working

The conclusion is that this combination does not work because of limitations of
the various components.  To sum up, Horde IMP uses PHP, that uses the c-client
library from UW-imap, that uses SASL, etc.  Now the problem is that c-client
cannot do password authentication with Kerberos, it requires that a TGT has
already been obtained and stashed away in the cache.  In the IMP (a Web-based
application) this is unlikely to be available.  So the authentication fails
and in an imperfect way at that (IMP tries a broken GSSAPI negotiation with the
server that ends in a closed connection and an incoherent message to the user).

So IMP must be prevented from trying GSSAPI Kerberos with the server, because IT
IS UNCAPABLE OF IT.  Removing cyrus-sasl-gssapi does it (c-client in IMP does
not find it anymore).  Cnnecting to a non-GSSAPI-enabled IMAP server does it too
(it is no longer offered for negotiation by the server).

In a normal application, one would use the mail_parameters interface in c-client
to do a DISABLE_AUTHENTICATOR that keeps c-client from choosing GSSAPI even if
available.  Or, at least, that's what I gather from reading the source.

Unfortunately, that function is not provided by the PHP imap extension module to
applications, so IMP cannot make use of it and can do nothing to avoid failing.

So I think the proper fix should come from PHP first and then from Horde IMP.

In the meantime, since all my PHP applications are Web-based and I cannot live
without GSSAPI in other applications, I have provisionally patched the imap.so
binary with emacs to smash the first GSSAPI string.  This makes the GSSAPI
authenticator invisible.

But I'll have to find a better workaround.
Comment 5 ed2019 2005-06-27 12:03:02 EDT
This bug is affecting me as well.  I'm trying to write my own application in PHP
that connects to our cyrus IMAP server.  The IMAP server is a different machine
than the web server.  The c-client on the web-server must not try to use GSSAPI
when it can't.  This code snippet will reproduce the bug:

$mbox = imap_open("{hostname:993/imap/ssl/novalidate-cert}INBOX", "name", "pw");

replace hostname with the name of the cyrus server, name and pw with the right
info for a user on that cyrus server.
Comment 6 ed2019 2005-06-27 12:03:40 EDT
For the record, i'm using RedHat Enterprise Linux 4 with:

Comment 7 ed2019 2005-06-27 12:42:41 EDT
Also, I do not have cyrus-sasl-gssapi installed on the PHP server, but it is
installed on the mail server.
Comment 8 Nalin Dahyabhai 2005-08-31 14:13:23 EDT
I'm not sure at this time why I ever suggested that removing cyrus-sasl-gssapi
from the client system would help, as the c-client library doesn't even use
Cyrus SASL, but implements the SASL mechanisms which it supports directly.

What you need, as Julio pointed out, is for the PHP IMAP module to provide some
way to call the C mail_parameters() function, at which point you can configure
the client to disable authenticators which you don't want to use (a short-term
alternative would be to rebuild libc-client with particular authenticators
disabled, and then rebuild php using that package, but that's hardly a general
Comment 9 Bill Nottingham 2006-10-18 14:34:54 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
If this issue is still present in a current Fedora Core release, please
open a new bug with the relevant information.

Closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.