living in a multi-mech world

[Philip Guenther]

On 4/29/07, Tom Yu <tlyu at mit.edu> wrote:
...
> Do we require pseudo-mechanisms such as SPNEGO to make GSS-API calls
> through function pointers obtained via a dlsym() equivalent?  (This
> might become unwieldy.)

Anything that can't be directly upon the normal GSS-API calls will
need to be aware of the direct mech access method, yes.  Hmm, perhaps
_that_ should be the core interface, and then both the normal GSS-API
calls and indirect calls (via the SPNEGO mech) could build on that.


> Do we have mechanism plug-in modules export symbols which are GSS-API
> entry point names systematically transformed, e.g., adding a short
> mechanism name prefix?
>
> Do we have mechanism plug-in modules export a function which returns a
> struct full of function pointers?  (This is similar to what our
> Sun-derived mechglue implementation currently does.)

I've found the latter to be simpler to implement.  It also lets the
function perform mech initialization without having to worry about the
portability or details of dload() invoked .init functions.


> What additional interfaces (if any -- preferably none) beyond the
> GSS-API do we require the mechglue layer to provide to plug-in
> modules?
...
> gss_buffer_desc doesn't have any way to identify which mechanism may
> have allocated the memory to which it points.  In a multi-mechanism
> implementation, this means either forcing all mechanisms to use the
> same memory allocator (intractable in various situations, including
> Windows DLLs, from what I understand) or somehow registering which
> memory blocks belong to which mechanisms so that mechglue can call the
> correct gss_release_buffer().

While forcing all mechs to use the same allocator may be intractable,
doing all the 'exported' allocation with the allocator from the SPI
may not be.  In an unrelated project using dynamicly loaded modules,
the plugin's functions all were given an extra argument that was a
pointer to a structure of callbacks including memory allocation and
release, a logging call, and a "look up config file entry" call.  The
plugins then used those callbacks for stuff crossing the
application<->plugin boundary, but plain malloc()/free() for stuff
local to the plugin.

The downside of that, of course, is that it may require copying data
between buffers in the mech's own SPI glue if the underlying mech
implementation is less flexible about how buffers are managed.  That
wasn't an issue in the project I'm thinking of, but it may be a
concern here.

Note that since these callbacks are provided as a structure of
pointers and not as exported symbols, there's no concerns about symbol
conflicts or overrides with multiple loads of the mech-glue layer.

If SPNEGO is built on the internal SPI (i.e., the "get direct access
to a specific mech" call) instead of trying to reinvoke the plain
GSS-API calls, then it could actually pass through the callback
structure that _it_ received down to the mech that it's invoking,
possibly avoiding buffer copying pain.


Philip Guenther
Sendmail, Inc