Ticket 5338: Race conditions in key rotation

[Ken Raeburn]

On Jun 24, 2008, at 03:09, Nicolas Williams wrote:
> Personally I'd prefer that you implement a single-threaded-but-async  
> KDC
> first.  Threading that will be easier, but at least you'll be abe to  
> max
> out (or get close to maxing out) one CPU and all the I/O that can  
> drive.
>
> This mostly means breaking up a couple of functions around all kdb
> operations.

And calls to get preauth information, which may be stored in external  
databases, and which may be implemented within plugins.  And calls to  
get authorization data... okay, we haven't implemented that yet, but  
again, there would potentially be long-running calls performed from  
within a plugin.  And OCSP calls to check certificates presented in  
PKINIT (which is implemented as a plugin).  And message exchanges to  
remote KDCs for PKCROSS, draft-kamada-krb-client-friendly-cross,  
whatever.

And there's the assumption that you can make all these other things  
play nicely with an async event loop that they don't even get to  
manage.  For remote-KDC interactions it's easy, but I don't see a way  
in the async OpenLDAP API, for example, to get a list of file  
descriptors on which async LDAP operations are pending.  You could  
spin some of these off into separate threads or processes that manage  
their own multiple async actions through whatever mechanisms are  
appropriate, and pass the data back to the main thread through a  
single unified async management mechanism; that would be a bit more  
limited than what Novell contributed, but perhaps simpler to analyze.

Ken