Howard Chu hyc@symas.com writes:
Russ Allbery wrote:
[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?
That's a really good question and I don't know the answer to that. I can imagine reasons why it would be both ways. This might be a good question to ask on kerberos@mit.edu, and I may go do that for my own curiosity.
Currently, the threading guarantees are not well-documented at all, which unfortunately joins the larger problem that the MIT Kerberos libraries are not well-documented. I know that's actively being worked on.
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.
1.4, for whatever it's worth, was the point at which the libraries were completely redone for thread safety. Various bugs in that support were fixed in 1.5.