issue with krb5_prompter_posix() design

[Mark Phalan]

On Wed, 2010-04-21 at 10:38 -0400, Jeffrey Hutzelman wrote:
> --On Thursday, April 15, 2010 04:49:30 PM -0500 Nicolas Williams 
> <Nicolas.Williams at oracle.com> wrote:
> 
> > It's an even worse ("worser") idea to make the choice of allocator
> > and/or synchronization primitives a global in the library.  OpenSSL, I'm
> > looking at _you_.
> >
> > All library API designers should expect multiple distinct callers in one
> > process and aim to have zero global variables/state.  Any state that one
> > is tempted to think of as global should be encapsulated in a handle
> > (such as krb5_context).  Look at any major library that you can think
> > of, say, NSS, PKCS#11, OpenSSL, libevent -- all of them have got this
> > wrong, and some of them have thankfully evolved to address this (e.g.,
> > libevent).
> 
> All of what you say is true, for allocators and a variety of other cases. 
> However, synchronization primitives are another beast entirely, because 
> they generally don't work unless everything in the process agrees on what 
> threading system is in use.  

I ran into this recently with respect to the pkinit plugin...

This (setting up synchronization primitives) is something that only the
application can easily control. Unfortunately it's a problem for
libraries which are supposed to be MT-safe.
The approach that OpenSSL takes is that the application sets the locking
callback functions. This works fine for applications using OpenSSL but
not very well when another library is using OpenSSL. Now that the pkinit
plugin (which uses OpenSSL) has been added to libkrb5 applications
calling into libkrb5 can end up in OpenSSL code. As far as the
application is aware it's not using OpenSSL and doesn't set any
callbacks.

Result: calls to krb5_get_init_creds* are no longer MT-safe.

The pkinit plugin could set the callbacks to the system default but this
approach is inherently racy (another library could be doing the same
thing).

-M