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): 1.5.24-23 How reproducible: Always 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 2. 3. 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.
Created attachment 40672 [details] Packet capture of broken GSSAPI authentication
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.
Do you have the cyrus-sasl-gssapi package installed on the system using PHP? If so, try removing it.
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 again. 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.
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.
For the record, i'm using RedHat Enterprise Linux 4 with: php-imap-4.3.9-3.6.i386.rpm
Also, I do not have cyrus-sasl-gssapi installed on the PHP server, but it is installed on the mail server.
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 solution).
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 http://www.redhat.com/rhel/migrate/redhatlinux/. 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.