Thread safety of MIT Kerberos w/GSSAPI
Jeffrey Altman
jaltman at secure-endpoints.com
Wed Feb 20 15:01:03 EST 2008
Ken Raeburn wrote:
> We currently assume that a security context is used in only one
> thread at a time, so you could switch between threads, just not use
> it simultaneously in multiple threads. But the person looking into
> it earlier concluded that there may not be anything besides the
> sequence number that's actually subject to race conditions there (and
> that window's probably small enough that it might "work fine in
> practice" much of the time, but no promises), so we could look into
> extending the concurrency for this case, and just do some internal
> locking around the sequence number accesses.
There should be no need for locking on platforms that support an atomic
increment operation which these days should be just about all of the
major platforms that we care about.
For Windows you want the InterlockedIncrement function. There are
32-bit and 64-bit versions. The value passed in must be quad aligned.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20080220/ed120382/attachment.bin
More information about the Kerberos
mailing list