living in a multi-mech world

[Nicolas Williams]

On Mon, Apr 30, 2007 at 12:12:50AM -0400, Tom Yu wrote:
> Questions:
> 
> Do we require RTLD_GROUP or "direct binding" functionality?

If RTLD_GROUP available, use it.  And always use RTLD_LOCAL too.

dlsym(RTLD_DEFAULT, symbol) is akin to "indirect binding" (though we
don't it that -- we don't have a term, near as I can tell, for the
opposite of direct binding).

dlopen()+dlsym() is akin to direct binding (because there's no room for
interposition when you look up the symbols directly in a particular
object or group).

Mechglue can't use direct binding to its plugins -- it has to dlopen()
and dlsym().

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

You shouldn't do that for symbols like malloc() that are outside the GSS
namespace.  So, no.

> 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.)

Yes, I think so -- so that the SPI can be close to the API, so that
mechanisms can be used standalone.  PKCS#11 does it like this (though
there applications are actually expected to dlopen() and dlsym() the API
symbols.

If any mechs should be usable standalone and via mechglue then they'll
need to use auxiliary filters for any symbols that they should be
getting from the mechglue.

> 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?

See above.  I.e., "no."  I could live with "yes," but I'd prefer "no."

> 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 abhor this.

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

SPIs that correspond to API extensions.

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

Several.

Buffer/memory management comes to mind.

Sam has pointed out before that gss_get/set_name/cred/context_specific()
functions would be most useful.

> ==============================
> 
> Problems with explicitly linking a mechanism with mechglue:
> 
> If one of the plug-in modules is a pseudo-mechanism such as SPNEGO,
> that pseudo-mechanism probably needs to make GSS-API calls to the
> mechglue layer.  It could depend explicitly on the mechglue library
> and make normal calls to the GSS-API entry points, but doing so has
> some risks.

Use RTLD_PARENT in dlopen() if it's available.

	RTLD_PARENT|RTLD_GROUP|RTLD_LOCAL

is what you want.  That should lead to plugins NOT having a declared
dependency on the mechglue, which is ugly, but it may be possible to
declare the dependency anyways and have it be ignored if symbols from
the parent group satisfy all the plugins' relocations.

> Consider an application that links against a specific (non-mechglue)
> mechanism library.  The specific mechanism library exports the
> GSS-API.  The application loads another library which depends on the
> mechglue library.  At some point, the library which depends on the
> mechglue library calls into the SPNEGO implementation by way of the
> mechglue library.  The SPNEGO library calls a GSS-API entry point,
> expecting to get the mechglue library, but instead gets the specific
> mechanism which the application explicitly depends on.

See above.

> One way to circumvent this problem is to have the SPNEGO library
> dlopen() the mechglue library and call the mechglue through function
> pointers, but that option seems distasteful.

Yes.  The other options:

 - direct binding from mechs to mechglue
 - use RTLD_PARENT when dlopen()ing mechs

> When using this "GSS-API as SPI" approach, issues arise, particularly
> when stackable mechanisms (or any mechanism that needs to call another
> mechanism by using the GSS-API) are involved.

These issues arise for any pseudo-mechanism.  They arise even if you
prefix the SPI symbols, which at makes some such issues go away provided
there's only ever one instance of mechglue loaded in any one process.

But as we've seen with LDAP, SASL, OpenSSL, and other things in the
context of PAM and the like you just can't assume that there will be
only one instance of the mechglue loaded in any process.

Better to isolate the object groups as much as possible as described
above.  Where the RTLD does not provide RTLD_GROUP/PARENT/LOCAL or
direct binding then simply document the resulting limitations.

Nico
--