[PATCH] Fix a gssapi issue where threads beyond the first would not be able to authenticate against the imap server. This is done by using the connection lock around the gssapi authentication code and resetting (and releasing) the kerberos state after success so that subsequent connections may make use of kerberos.

sjh at foolishpride.org sjh at foolishpride.org
Wed Jun 1 04:29:56 BST 2011


From: Scott Henson <shenson at redhat.com>

---
 offlineimap/imapserver.py |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/offlineimap/imapserver.py b/offlineimap/imapserver.py
index 7703879..a20bd88 100644
--- a/offlineimap/imapserver.py
+++ b/offlineimap/imapserver.py
@@ -213,6 +213,7 @@ class IMAPServer:
                     try:
                         # Try GSSAPI and continue if it fails
                         if 'AUTH=GSSAPI' in imapobj.capabilities and have_gss:
+                            self.connectionlock.acquire()
                             self.ui.debug('imap',
                                 'Attempting GSSAPI authentication')
                             try:
@@ -223,8 +224,12 @@ class IMAPServer:
                                     'GSSAPI Authentication failed')
                             else:
                                 self.gssapi = True
+                                kerberos.authGSSClientClean(self.gss_vc)
+                                self.gss_vc = None
+                                self.gss_step = self.GSS_STATE_STEP
                                 #if we do self.password = None then the next attempt cannot try...
                                 #self.password = None
+                            self.connectionlock.release()
 
                         if not self.gssapi:
                             if 'AUTH=CRAM-MD5' in imapobj.capabilities:
-- 
1.7.5.1





More information about the OfflineIMAP-project mailing list