Ticket 5338: Race conditions in key rotation

[Nicolas Williams]

On Tue, Jun 24, 2008 at 09:30:12AM -0400, Ken Raeburn wrote:
> 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  

Today that's all part of the KDB.

> get authorization data... okay, we haven't implemented that yet, but  

No, you haven't.  It'd be nice, but it'd be even nicer if you add it the
right way (with a callback / event registration) so that the public
interfaces you add don't prevent this design.

> 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  

Of course.  It's worth doing.

> remote KDCs for PKCROSS, draft-kamada-krb-client-friendly-cross,  
> whatever.

Right, PKCROSS doesn't have any KDC-KDC message exchanges, while the
latter does.

> 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  

No such assumption.  If you begin by reducing the number of synchronous
sleep points you win a lot.  You can do this piecemeal, over time,
rather than having to do this all at once.

> 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  

Yes, you need to have helper threads for things like libldap.  It's not
a big deal.  (In this case the helper thread blocks in ldap_result(),
and arranges for event dispatching based on the message IDs of the LDAP
results.)

> 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.

Right, that's how these helper threads would work.

Yes, it's *much* simpler to analyze because everything part of the
system can be single threaded and the only interesting synchronization
points are the ones by which: a) events are queued up that, b) helper
threads signal the dispatch thread (both trivial things).

Later you can multi-thread the parts of the KDC that do the krb5 work
while adding a big lock around the KDB and other plugins.

Later you can make the KDB and plugins thread-safe and remove the big
locks.

A design that allows you to do the work piecemeal has a lot going for
it, IMO.

Nico
--