Ticket 5338: Race conditions in key rotation
raeburn at MIT.EDU
Mon Jun 23 19:16:42 EDT 2008
On Jun 23, 2008, at 18:03, Nicolas Williams wrote:
> It would help too if krb5kdc were multi-threaded, otherwise clients
> 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/
More information about the krbdev