[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multi-mechanism gssapi





Kevin Coffman wrote:
> This isn't exactly a heimdal question, but has heimdal implications.
> 
> We have a shared gssapi "glue" library which allows an application to 
> use multiple gssapi mechanisms.  The functions in this glue library 
> must be named "gss_*".  It dynamically loads mechanism libraries and 
> resolves function pointers.  However, the functions in the heimdal 
> gssapi library have the same "gss_*" names.  I run into problems with 
> dynamic linking/loading the heimdal library because when a function 
> within the heimdal library tries to call a gss_ function, if that 
> function has already been resolved to the glue's version then the 
> heimdal function calls the glue version instead of its own.
> 
> Does anyone know of a way to properly get around this w/o changes to 
> the current heimdal library?  If not, is there any chance of adding a 
> prefix to the heimdal gssapi function names and wrappers for when it is 
> used stand-alone?  (This is how the MIT library is built.)

If you are linking the libraries as shared, you could use the -B symbolic
options. (IIRC) this will causes entries in the library to be resolved
when the library is built if it can be resoloved within the library.

There may also be a way to use dlopen flags to do the same thing.

(I sent a similiar note to you, nfsv4 and heimdal-discuss on 4/27/2004.)

  NCSA has a mechglue that addresses some of the same problems.

  http://grid.ncsa.uiuc.edu/gssapi-mechglue/


I ran in to a similar problem with OpenSSL and KX509:

> The shared libcrypto needs to be built with -B symbolic on Solaris.
> 
> This was discovered using OpenSSL-0.9.7b, on Solaris 5.7 with
> Netscape when libcrypto is loaded with the University of Michagan's
> kpkcs11.so. The librcrypto RAND_status eventially calls the update 
> routine in evp/m_sha1.c which calls the Netscape version of SHA1_update 
> rather then the version in libcrypto. This caused a seg fault, as the
> SHA1_CTX num variable would get overwritten.   






> 
> 
> 
> 

-- 

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