There's a catch however, Kerberos 5 implementations available for Linux / UNIX are not re-entrant and thus cannot be used in multi-threaded applications without serializing all code paths accessing the Kerberos API.
It might be hard to believe but, for once, Microsoft has managed to create something that is superior to Linux / UNIX equivalents (to be fair, there are other exceptions as well): The Microsoft Windows Kerberos implementation is fully re-entrant. Doesn't come as a surprise to me because Microsoft simply couldn't afford to provide an API that isn't - at last, Windows itself and practically all applications and services are inherently multi-threaded. In my opinion, that is exactly the reason why there's no re-entrant MIT Kerberos available on Linux / UNIX: Except for most GUI applications, common daemons are single-threaded and use a process model instead that often is fork(2) driven:
- pop3d / imapd variants
- Apache 1.3 and earlier
Granted, the number of installations dealing with multi-threaded applications (a small subset already) as well as Kerberos (in most cases, it's only an issue for medium to large-scale installations) is not exactly substantial - not substantial enough for supporting the refactoring of existing implementations towards re-entrance. This is a strong case of a minority being discriminated against, please spread the word to make a difference ;)
Seriously, in the Linux / UNIX world, there's currently no satisfactory solution available because even those saying that serialization solves it all are mistaken. Consider a large-scale Kerberos-enabled application using Apache as an interface to application users. In each application module, Kerberos may be used and calls must be synchronized. However, that's easier said than done because that synchronization must include all modules, it must span the whole process to solve this issue. If modules originate from more than one project or vendor, you've lost already - process-wide synchronization would require an agreement across all modules on the means of synchronization. If all modules are controlled by a single project or vendor and/or the source is available for those that are controlled by a different group, re-entrance can be established using a consistent locking protocol (e.g. by providing access to a single, process-wide mutex that is owned by a module all other modules have access to). Otherwise, there's practically no way to work around the lack of re-entrance (except for maybe preloading a library implementing Kerberos symbols that basically wraps all externals and serializes access or rolling your own release based on an open source Kerberos implementation).
You see, this dilemma is nerve-wracking because there's no satisfactory solution. Most likely, several more years will have to pass (where more multi-threaded daemons can emerge and require multi-threaded Kerberos implementations) until this problem will be solved with the availability of a re-entrant implementation...
How do you cope with Kerberos and thread-safety on Linux / UNIX platforms?