Re: Mechanism extensions and the GSSAPI

["Douglas E. Engert" <deengert@anl.gov>]

Kevin Coffman wrote:
> 
> I agree with Nico that this is an excellent survey of the options.
> 
> > Here is what I believe the goal is.  We want to find a way to have
> > general extensions to GSSAPI mechanisms.  Sun and apparently other
> > parties as well would like to have the API between the multi-mechanism
> > glue layer and the mechanism implementation be the GSSAPI.  That means
> > that any extensions we need to the glue layer need to be things we are
> > willing to standardize.  It might also mean that there can be no
> > up-calls from the mechanism to the glue layer.
> 
> Yes, I agree this makes the life of the "core glue" library sane.
> 
> >                         Shim around Ioctl
> >
> > Mechanisms could provide a shim library that exports
> > mechanism-specific APIs that end up calling the appropriate gss_ioctl
> > function.  That means that the responsibility of encoding the
> > arguments  is now the mechanism's rather than the application's.  This
> > proposal is as easy to use as the upcall approach although it is as
> > hard to write  for mechanism authors as the ioctl approach.
> >
> >
> > This has the same disadvantage of the ioctl approach if  multiple
> > objects are  used.
> >
> > This approach solves the dynamic linking problem in that there is no
> > reason the shim cannot be in its own dynamic object.
> 
> I think I agree with Nico that this seems like the best option, but
> let me see if I fully comprehend.
> 
> - When building the application, you need to know whether it is
> linking against a single-mechanism gssapi implementation or a
> multi-mechanism glue layer.  Either way, it's interface doesn't
> change.
> 
> - If the app is linking directly with the single-mech
> implementation, and uses mech-specific functions, it all happily
> works.
> 
> - If the app is linking with the multi-mechanism "core glue" and
> uses mech-specific functions, it needs to know to link with the
> mech-specific "glue shim(s)" and not directly against the mech-specific
> library. (i.e. the "core glue" library shouldn't have to know about
> mech-specific glue shims.)

There may be some issues with regards to linking against shared libraries
vs using dlopen/dlsym.  Many mechglue implementations use dlopen to 
load a number of mechs. 

If the application needs to use mech specific routines, and links against
the mech shared library, it might pickup some additional or wrong entry
points, since the actually implementation of the mech is not really 
known until run time.   

So the mech-specific/implementation-specific "glue shim" may need to be 
their own shared or dynamic libraries and the use of dlopen with RTLD_GLOBAL
vs RTLD_LOCAL may need to be looked at closely. 



> 
> Is this what you were thinking?
> 
> _______________________________________________
> krbdev mailing list             krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev

-- 

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439 
 (630) 252-5444