Ticket 5338: Race conditions in key rotation

[Ken Raeburn]

On Jun 23, 2008, at 18:03, Nicolas Williams wrote:
> It would help too if krb5kdc were multi-threaded, otherwise clients  
> can
> time out if too many hit the master at once, and meanwhile the  
> master is
> not maxing either its CPU nor its I/O.

We've gotten requests (and arguments) both pro and con...

Certainly we're going to need to address the fact that talking to an  
LDAP server or other database back end may not be instantaneous.  And  
other possible extensions being discussed at the IETF will also  
require the KDC to wait for some external service.

Most sites seem to have no problem with one (often cheap or outdated)  
machine servicing all KDC requests using a db2 database, but there are  
probably cases at larger sites where that's not true.  I have no idea  
if CPU power, disk bandwidth, or network bandwidth would be the likely  
bottlenecks.  Single-threaded processing power doesn't seem to be  
increasing very quickly any more though.  I would guess that PKINIT  
would add a bit to the CPU load, though obviously only for the  
relatively infrequent AS-REQ exchanges.

On the flip side, there's the argument that going from single-threaded  
code to multi-threaded is likely to introduce race conditions into  
existing code if you're not *extremely* careful, and they'll be hard  
to spot.  Using a multi-process model could conceivably work, but also  
requires some careful re-architecting, though without as much risk of  
memory-corrupting race conditions.

We do have a patch sitting on a branch in the subversion repository at  
MIT, which makes part of the KDC multithreaded, specifically, allowing  
multiple parallel queries to an LDAP server to be in progress.   
Unfortunately, I haven't had time to exercise it much.  If you (or  
anyone else) would like to take a look, it's at svn://anonsvn.mit.edu/ 
krb5/branches/mt-kdc/.

Ken