Ticket 5338: Race conditions in key rotation
Nicolas.Williams at sun.com
Tue Jun 24 12:08:02 EDT 2008
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
> 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,
Right, PKCROSS doesn't have any KDC-KDC message exchanges, while the
> 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
> 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
A design that allows you to do the work piecemeal has a lot going for
More information about the krbdev