GNOME Bugzilla – Bug 554182
GSSAPI not working
Last modified: 2009-07-16 12:35:35 UTC
Please describe the problem: I have an IMAP account configured for GSSAPI, yet whenever I open this GSSAPI configured account, I am still asked for a password via the "Enter Password" dialog box. Yet, as you can see I have valid tickets: $ date; klist Sun Sep 28 10:10:57 EDT 2008 Ticket cache: FILE:/tmp/krb5cc_1001_IqGM9r Default principal: brian@ILINX Valid starting Expires Service principal 09/28/08 09:54:19 09/28/08 19:54:19 krbtgt/ILINX@ILINX renew until 09/29/08 09:54:19 09/28/08 10:00:12 09/28/08 19:54:19 imap/mail.example.com@ILINX renew until 09/29/08 09:54:19 Kerberos 4 ticket cache: /tmp/tkt1001 klist: You have no tickets cached Steps to reproduce: 1. configure kerberos and imap to use kerberos 2. configure evolution account for kerberos 3. try to open account Actual results: I get prompted for a password Expected results: The account is opened, without a password using the kerberos ticket Does this happen every time? yes Other information:
Can confirm this. The same issue, evolution 2.24.0. Copying the original bug report on launchpad for Ubuntu, however considered the bug might be upstream. Binary package hint: evolution OS: Ubuntu Intrepid Beta fully up to date as of 18.10.2008 We use company wide Kerberos authention for several different services, amongst them email IMAP/SMTP the server used is Debian Etch, Imap server Dovecot (debian repos) with Kerberos native and pass-through authentication enabled. Symptoms: Evolution configured for GSSAPI authentication prompts for password authentication anyway. (the kerberos ticket is correctly requested and obtained as shown with klist). despite the presence of krb. ticket evolution keeps prompting for a password until a correct credentials are provided (pass through authentication) Identical setup works fine on Hardy 8.04.1
Same here. Evolution 2.24.1. Also, I have observed that after pressing the authentication "Check for supported types" button, both Plain and GSSAPI are available. My server does not support or advertise Plain support: * OK Dovecot ready. a capability * CAPABILITY IMAP4rev1 SASL-IR SORT THREAD=REFERENCES MULTIAPPEND UNSELECT LITERAL+ IDLE CHILDREN NAMESPACE LOGIN-REFERRALS STARTTLS AUTH=GSSAPI a OK Capability completed. Perhaps this is related. Thanks!
I've confirmed this problem. Evolution 2.22 (and earlier) works fine to authenticate to our IMAP server using GSSAPI/Kerberos. Evolution 2.24 is broken (won't use GSSAPI/Kerberos to authenticate, even though it does get a service ticket). My co-worker updated to Fedora 10 (with Evolution 2.24) and immediately hit this problem. Everyone in our office with Evo 2.22 has no problem, but everyone with Evo 2.24 has the problem.
Also tracked in https://bugzilla.redhat.com/show_bug.cgi?id=477808
This is very similar issue as in the bug #552583. It took me most of today to figure out what's going on here, but I think I got it. The problem is with camel_session_get_service, or maybe even better with the way how IMAP checks for the same URL and/or the Evolution's mail component is looking for a service by the URI of the folder, not by the right service URI. Just try to run this and checkout yourself: gdb evolution --ex "b camel_imap_store_init" --ex r You'll see that there are created many services for the one account, one in
+ Trace 211325
I suppose, because of the changes in bug #552583 we didn't select the right service, with fully specified connection URI, but we used that different one. When I stop to compare and hash URL in IMAP with the authmech, then it starts to work as expected. Furthermore, I also noticed asking Evolution 2.22 for a password for already connected IMAP account (through GSSAPI), and cancelling the password prompt didn't have any effect on the UI, I was able to download new messages from the server. Thus I guess it was there even before, but "recent" changes uncovered this issue much more (or not many people used other than PLAIN authmech/or server allowed both methods). The only question is, how to deal with this.
Created attachment 125933 [details] unfinished approach This is the other approach I tried before I realized it has too many dependencies. Most bad is with mail_tool_uri_to_folder, "X-Evolution-PostTo" header, and probably some other too. One thing I found during this, we search for an account for the folder even it's not necessary, it's stored in an EMFolderTreeModelStoreInfo structure, together with a store and other things. But this doesn't work for em_folder_tree_set_selected_list, thus it doesn't matter much. So adding it here just for fun.
Created attachment 125935 [details] [review] proposed eds patch for evolution-data-server; I dropped checking of the 'authmech' in all providers, where it was explicitly used. It fixed the issue for me here. I finally found out that the 'authmech' is ignored in mail_config_get_account_by_source_url, mail_config_get_account_by_transport_url thus the camel_session_get_service will return same service as the account now. Just to mention: after this, there is no good reason to have setup an imap account for the same server, with the same user, but with different authentication method. In such cases, it'll depend on the order in an account list, which of those two will be used. Probably no big deal for an ordinary user.
Some of the providers use camel_url_equal() for their url_equal() method, which does check 'authmech'. POP3 and SMTP among them. See the chart I put together at: http://bugzilla.gnome.org/show_bug.cgi?id=552583#c24
I know, I left them because they are on the safe side, at least now. None of them would be shown in the folder tree.
Seems fine for stable/trunk
Committed to trunk. Committed revision 9885. Committed to gnome-2-24. Committed revision 9886. If it'll show up as not enough, then we can add camel-url.h camel_url_hash_uhp, camel_url_equal_uhp for checking in user, host and port only and use then in all providers. Maybe sometime later, will see.
(In reply to comment #11) > Committed to trunk. Committed revision 9885. > Committed to gnome-2-24. Committed revision 9886. Is this before or after 2.24.3?
Based on the http://svn.gnome.org/viewvc/evolution-data-server/branches/gnome-2-24/NEWS it's before. This bug is mentioned there, and revision of the NEWS file is also higher than the mention above. Doesn't it work?
(In reply to comment #13) > > Doesn't it work? Yes, it does in fact appear to work now! Much thanx! It eases the pain of the continuous other crashes at least in as much as I don't have to keep entering my password on every restart.
*** Bug 315166 has been marked as a duplicate of this bug. ***