Projects/GSS-API mechanism plug-in support

This is an early stage project for MIT Kerberos. It is being fleshed out by its proponents. Feel free to help flesh out the details of this project. After the project is ready, it will be presented for review and approval.

GSS-API mechanism plug-in support

We want to have loadable mechanism plug-in modules for GSS-API. This will allow third parties to write GSS mechanism plug-in modules for use with our code.

Goals

• ordinary mechanism modules need only provide GSS-API C bindings
• pseudomech modules do not need to know implementation-specific things
• allow pseudomech modules to call the mechglue somehow
• allow pseudomechs to "pop" themselves off the stack, e.g. SPNEGO gets out of the way and replaces its context with underlying mechanism once context negotiation is complete
• do not require modules to do anything special for memory management; each module's gss_release_buffer() gets used for memory it has allocated

OS requirements

• RTLD_LOCAL or equivalent functionality to avoid injecting plug-in symbols into global namespace
• modules should work with RTLD_GROUP but not require it

Requirements for mechglue

• register gss_buffer_t values from mechanisms in order to call correct gss_release_buffer()
• register its own gss_context_t values in order to detect pseudomech "pop"
• other things may need registration in order to deal with pseudomechs, e.g.
  • creds
  • names
• gss_dlsym() (or whatever we call it) for pseudomechs to obtain mechglue GSS-API entry points
• provide gss_dlsym() to pseudomechs at module load time

Requirements for mechanism modules

• provide GSS-API C bindings (gss_*) entry points
• do not link against mechglue
• only use internal names to call internal entry points

Additional requirements for pseudomech modules

• provide entry point (name TBD) for mechglue to call at module load time to provide gss_dlsym() entry point
• use gss_dlsym() to obtain mechglue entry points
• always call other mechanisms via the mechglue
• must not internally register objects obtained from other mechanisms

Design

Pointer registration

• thread-safe
• thread-hot?
• performance
  • lock contention
  • cache latency
  • can it keep up with a mostly no-op gss_wrap(), for example?