krb5 thread support and excess support libraries -- seeking opinions, options
Nicolas.Williams at sun.com
Thu May 6 18:15:45 EDT 2004
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
> >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
> 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.
More information about the krbdev