[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Help with SASL/GSSAPI to remote Kerberos server



Russ Allbery wrote:
Howard Chu<hyc@symas.com> writes:
Wes Modes wrote:

Specifics of my configuration:

     * OS: Red Hat Enterprise 4 v2.6.9
     * OpenLDAP v2.2.13
     * Local MIT Kerberos5 v1.3.4
     * KDC: MIT Kerberos5 v?
     * Cyrus SASL v2.1.19
All of these versions are far outdated, and MIT Kerberos is known to be
unsafe in a threaded environment (and yes, OpenLDAP slapd is threaded).

That is definitely true of that version of MIT Kerberos, which if I recall correctly made no attempt at thread safety whatsoever.

The MIT Kerberos team believes that they've fixed all the thread safety
correctness bugs, within the thread safety guarantees that the library
attempts to provide [1], in the current release (1.6.3) and would welcome
bug reports for any remaining problems.  I believe that OpenLDAP does meet
the prerequisites for using MIT Kerberos safely.

Hmm....

[1] MIT Kerberos only supports thread safety provided that no single
     krb5_context is used from multiple threads.  Each thread needs to have
     its own krb5_context.  In a GSSAPI context, this means that you must
     ensure that only one thread uses each GSSAPI security context.

Is this condition strictly on the authentication process, or also on the encryption library in general?


There are no such guarantees inside slapd. There is one context per connection, but multiple operations may be active on a single connection at the same time, and each operation executes in a separate thread. But since there can only be one authentication outstanding per connection, it may be OK.

Otherwise, while only one thread at a time can read a connection, and only one thread at a time can write on a connection, both reads and writes can occur simultaneously. This is a very common case for a client that issues a batch of asynchronous operations and streams the replies. From your description above, this case will still break with MIT Kerberos. I gave up on the MIT code back in 1.3.x, so I haven't tested this lately. Someone who cares about MIT's code probably should take a look at it though.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/