Projects/GSS-API mechanism plug-in support
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.
- 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
- 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.
- 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
- lock contention
- cache latency
- can it keep up with a mostly no-op gss_wrap(), for example?