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

[Ken Raeburn]

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?

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.

If I get the time, I should look at that more closely.

Ken