Re: MEMORY credential cache interop between Heimdal and MIT?

[Ken Raeburn <raeburn@MIT.EDU>]

On Aug 16, 2007, at 16:51, Michael B Allen wrote:
> On Thu, 16 Aug 2007 15:03:24 -0400
> Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
>
>> Michael:
>>
>> Have you examined the krb5_cc_xxx API that both MIT and Heimdal  
>> implement?
>>
>> If krb5_cc_register() was exported, would that satisfy your  
>> requirement?
>>
>> It would permit you to add any credential cache implementation of  
>> your
>> choice to the library at run-time.
>
> Hi Jeffrey,
>
> That wouldn't work. The krb5_cc_register function would only register
> cc ops with the implementation with which you're linked [1]. So if
> your program is linked with Heimdal and it called a cURL library that
> was linked with MIT, the krb5_cc_register call will have no effect
> on the ccache code used by cURL. And even if you could call the other
> implementation's krb5_cc_register using some crazy dlopen trickery the
> internal structures are not the same.

The idea I had (which I guess I didn't outline well) was to either  
use dlopen so you can independently access both implementations, or  
create multiple shared objects, for example:

obj1.so
   implements a cache
   links against obj2.so and obj3.so
   library init function calls register_cache_with_mit,  
register_cache_with_heimdal
obj2.so
   links against MIT code
   implements register_cache_with_mit
obj3.so
   links against Heimdal code
   implements register_cache_with_heimdal

Then set LD_PRELOAD=/path/to/obj1.so, or link the application against  
it.  Unless the dynamic linker loads multiple copies of the  
libraries, this ought to get you a shared credential cache between  
the implementations for that process.  The core implementation can  
define its own data structures, and the methods for each  
implementation can do the translation.

However you do it, you'd probably wind up wanting to compile multiple  
object files anyways, to avoid confusion between the MIT and Heimdal  
type names and such.  Though you could simplify it from the above,  
merging either obj2.so or obj3.so into obj1.so, for example.  Or  
linking a non-shared obj1.o directly into the application instead of  
as a shared library object.  Et cetera....

Kind of ugly, but it would get the originally requested functionality  
with today's released libraries.

Ken