Russ Allbery wrote:
Howard Chuhyc@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.19All 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.