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 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 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 ===
  
=== OS requirements ===
Line 24: Line 26:
   
 
* provide GSS-API C bindings (gss_*) entry points
  
* provide GSS-API C bindings (gss_*) entry points
  +
* do not link against mechglue
 
* only use internal names to call internal entry points
  
* only use internal names to call internal entry points
   
−
=== Requirements for pseudomech modules ===
 +
=== Additional requirements for pseudomech modules ===
   
⚫
* use dlsym() to obtain mechanism entry points
  
  +
* provide entry point (name TBD) for mechglue to call at module load time to provide gss_dlsym() entry point
⚫
* must not register objects obtained from other mechanisms
  
  ⚫
* use gss_dlsym() to obtain mechglue entry points
  +
* always call other mechanisms via the mechglue
  ⚫
* must not internally register objects obtained from other mechanisms

Revision as of 16:00, 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.

Goals

  • ordinary mechanism modules need only provide GSS-API C bindings
  • pseudomech modules do not need to know implementation-specific things
  • 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 gss_context_t values from mechanisms in order to detect pseudomech "pop"
  • gss_dlsym() (or whatever we call it) for pseudomechs to obtain mechglue GSS-API entry points

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
Retrieved from "https://k5wiki.kerberos.org/wiki?title=Projects/GSS-API_mechanism_plug-in_support&oldid=104"