Howard Chu <hyc(a)symas.com> writes:
Russ Allbery wrote:
>  MIT Kerberos only supports thread safety provided that no
> 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(a)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,
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.
Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>