living in a multi-mech world

[Sam Hartman]

First, Tom, thanks for an excellent write up of the situation.


>>>>> "Tom" == Tom Yu <tlyu at MIT.EDU> writes:

    Tom> We have given some thought to pursuing the concept of making
    Tom> the GSS-API C bindings be the actual SPI for plug-in modules,
    Tom> i.e., the ABI which each module exports would exactly
    Tom> correspond to the GSS-API.  This has the advantage that an
    Tom> application could link against either the mechglue layer or
    Tom> directly against a specific GSS-API mechanism implementation.

I think that's not really the key advantage.  There are platforms (OS
X) where a plugin and shared library are different, so you can't
really depend on being able to link to a mechanism.  But what making
the SPI be the GSS_API does is allows people to write mechanisms that
are mostly or completely independent of the mechglue layer.  If we do
anything else, we really should work to standardize the SPI.

    Tom> I'll provide a set of working assumptions to start with,
    Tom> followed by a list of the questions it might be most useful
    Tom> to have answers for.  There are also descriptions of some of
    Tom> the problems we may face in this space.

    Tom> To provide a uniform basis for discussion, let's assume:

    Tom> * A "dynamic" or "shared" library on a platform can also
    Tom> function as a runtime-loadable object.

I think this assumption is sometimes false.

Add another assumption:

* Shared objects have no unresolved symbols.  I.E. they explicitly
declare dependencies on any libraries they import symbols from.  As an
implication, they import no symbols from the application.

    Tom> ==============================

    Tom> Questions:

We use it when available.

    Tom> Do we require RTLD_GROUP or "direct binding" functionality?

    Tom> Do we preclude symbol interposition upon mechanism plug-in
    Tom> modules, e.g., do we preclude the sort of symbol
    Tom> interposition that a user might want to use for malloc
    Tom> debugging?

We don't go out of our way to break it, but if it ends up broken,
that's OK.

    Tom> Do we require pseudo-mechanisms such as SPNEGO to make
    Tom> GSS-API calls through function pointers obtained via a
    Tom> dlsym() equivalent?  (This might become unwieldy.)

That seems OK, provided that such mechanisms don't need to know how to
find mechanism libraries.  I.E. importing such an interface from the
mech glue would be OK, but asking each mechanism to do its own dlopens
sounds highly problematic.

    Tom> Do we have mechanism plug-in modules export symbols which are
    Tom> GSS-API entry point names systematically transformed, e.g.,
    Tom> adding a short mechanism name prefix?

I'd like to avoid requiring this.

    Tom> Do we have mechanism plug-in modules export a function which
    Tom> returns a struct full of function pointers?  (This is similar
    Tom> to what our Sun-derived mechglue implementation currently
    Tom> does.)

I'd like to avoid this  especially if the structure is not standardized.

    Tom> What additional interfaces (if any -- preferably none) beyond
    Tom> the GSS-API do we require a mechanism to export?
hopefully none

    Tom> What additional interfaces (if any -- preferably none) beyond
    Tom> the GSS-API do we require the mechglue layer to provide to
    Tom> plug-in modules?

Possibly several.