logo_kerberos.gif

Difference between revisions of "Projects/GSS-API mechanism plug-in support"

From K5Wiki
Jump to: navigation, search
m (checkpoint)
m (checkpoint)
 
Line 3: Line 3:
 
== GSS-API mechanism plug-in support ==
 
== GSS-API mechanism plug-in support ==
   
We want to have loadable mechanism plug-in modules for GSS-API.
+
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 ===
 
=== Goals ===
Line 9: Line 9:
 
* ordinary mechanism modules need only provide GSS-API C bindings
 
* ordinary mechanism modules need only provide GSS-API C bindings
 
* pseudomech modules do not need to know implementation-specific things
 
* 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
 
* 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
 
* do not require modules to do anything special for memory management; each module's gss_release_buffer() gets used for memory it has allocated
Line 20: Line 21:
   
 
* register gss_buffer_t values from mechanisms in order to call correct gss_release_buffer()
 
* register gss_buffer_t values from mechanisms in order to call correct gss_release_buffer()
* register gss_context_t values from mechanisms in order to detect pseudomech "pop"
+
* 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
 
* 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 ===
 
=== Requirements for mechanism modules ===
Line 35: Line 37:
 
* always call other mechanisms via the mechglue
 
* always call other mechanisms via the mechglue
 
* must not internally register objects obtained from other mechanisms
 
* 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?

Latest revision as of 18:01, 8 January 2008

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?