[Date Prev][Date Next]
Re: Help with SASL/GSSAPI to remote Kerberos server
Howard Chu <firstname.lastname@example.org> writes:
> Russ Allbery wrote:
>>  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 email@example.com, 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.
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>