[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: MEMORY credential cache interop between Heimdal and MIT?
On Aug 16, 2007, at 16:51, Michael B Allen wrote:
> On Thu, 16 Aug 2007 15:03:24 -0400
> Jeffrey Altman <email@example.com> wrote:
>> Have you examined the krb5_cc_xxx API that both MIT and Heimdal
>> If krb5_cc_register() was exported, would that satisfy your
>> It would permit you to add any credential cache implementation of
>> 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 . 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:
implements a cache
links against obj2.so and obj3.so
library init function calls register_cache_with_mit,
links against MIT code
links against Heimdal code
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.