krb5 thread support and excess support libraries -- seekingopinions, options

[Douglas E. Engert]

Ken Raeburn wrote:
> 
> On May 6, 2004, at 09:59, Douglas E. Engert wrote:
> 
> > But we now have the IETF KCRYPTO draft, which was meant to allow for
> > the user of the K5 crypto without the rest of Kerberos. So can the
> > k5crypto be setup to support this?
> 
> It can be, yes.  It could still be done even if the k5crypto and krb5
> libraries were merged; there'd just be a lot more exported symbols to
> ignore.
> 
> Actually, you may not be able to use the k5crypto code without the krb5
> library.  Some of the crypto functions take a krb5_context parameter,
> and while sometimes it's not used, I don't think we're generally
> asserting that it can be NULL.  I don't recall if there are cases where
> NULL will actually break things right now, but if we start doing stuff
> like caching key schedules and derived keys, the krb5_context would be
> one obvious place to store the cache.  So I think it's safe to say that
> even if you don't use the krb5 protocol, just the crypto functionality,
> you still need the krb5 library.
> 
> >> For that matter, we should be able to link apps and libraries against
> >> just the libraries they use directly -- e.g., link against
> >> libgssapi_krb5 only, if it doesn't do any Kerberos stuff directly, and
> >> have the dependencies recorded in the library pull in the other needed
> >> libraries, preferably without messing with the symbol namespace,
> >> either.  But I don't think I've got time to investigate that soon for
> >> N
> >> platforms.
> >
> > If using shared libs, every platform I have seen only needs the gss
> > lib,
> > and it will force the rest of the libs to be loaded.
> 
> (1) Does the application see the krb5 symbol names in that case?

The point would be that if the application does not need access to the 
lower level library, then  it does not need to know about it a link time.
If it did,then you would need to include it during link. This is for dynamic libs 
only of cource.

With the right use of dlopen and friends an aplication at run time could find
other routines in libs that have been loaded.   

> (2) Yes, our installed libs can be used that way.  I'd like to be able
> to do such things in our build.  But it's a minor point.

Understood. 

One point here would be if an aplicaiton needs GSS, only then it only needs
to link to the libgssapi.so. It does not care which GSS implementation, 
or if this is a mechglue. The dynamic loader will get all the other
libraries at run time. 

An example of this was when I took a Globus applicaiton linked against their 
gssapi library, and replaced the lib with with a mechglue library. 
It works as expected. I have done this on Solaris. 
On Windows, I slipped in a mechglue and got the gssftp to use either Globus GSI
or MIT Kerberos. 


> 
> Ken

-- 

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