krb5 thread support and excess support libraries -- seeking opinions, options

[Nicolas Williams]

On Thu, May 06, 2004 at 06:05:45PM -0400, Ken Raeburn wrote:
> On May 6, 2004, at 15:49, Nicolas Williams wrote:
> >Aside: in our discussions with Sam about derived key caching we
> >discussed having a new krb5_keyblock with the keys cached therein, with
> >a new magic value and constructors/destructors for krb5_keyblock that 
> >do
> >the right thing.  The krb5_context is not really a good place to stored
> >derived keys anymore than it is a good place to put extended
> >get_init_creds prompts.  But there could be other things you might want
> >to cache in a context structure of some sort...
> 
> Yes, I remember; the key block is a better place for key-derived 
> information in general, but we haven't done it yet.
> 
> If I remember right, the idea was to call some init routine in the 
> library which would set up any additional data needed -- like a mutex 
> to protect accesses to the list of derived keys, etc.  For 
> multiple-thread access we get some interesting issues, like: If we're 
> caching the last N derived keys, how do we know when it's safe to 
> remove one, and the data hanging off of it, like its key schedule?  
> Reference counts?  Some sort of multiple-reader lock?

You could just state: one thread per-keyblock.

Also, you could release derived keys only when the containing keyblock
is released.

> The current key blocks are thread-safe once set up, because nothing 
> gets modified, and there's no cache involved.
> 
> >This should depend on how the gss mech is linked.  I don't know about
> >other linkers, but on Solaris you can link the gss mech so that symbols
> >from its dependencies do not pollute the caller's namespace.
> 
> I would think that would generally be desirable.  Though I could 
> imagine an application loading libgssapi.so, then using dlsym to see if 
> certain Kerberos functions were loaded and if so, calling them; such an 
> application might not want to load the Kerberos code unless GSSAPI had 
> done so already.

Ick.  It's ok to have one library pull in others into the application
and then for the app to load those same libs again -- runtime linkers
should generally ensure that only one instance is loaded of each library
pulled into the application's namespace, methinks.  But yes, -B group /
dlopen(..., RTLD_GROUP) or RTLD_LOCAL are good, though not necessarily
available on all platforms.

Nico
--