Re: MEMORY credential cache interop between Heimdal and MIT?

[Michael B Allen <miallen@ioplex.com>]

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.

You could make the cc interface a dlopen style plugin (didn't you suggest
that yesterday?) but that would drag a log of ccache code with it. All
implementations would probably need to standardize some data structures
which could be a little sticky. And by itself it wouldn't give you shared
secure storage or fancy access control (the later being the feature that
I'm really looking for).

What I'm thinking is that there could be some kind of shared storage
with fancy access control that doesn't specify anything about
the format of objects. The simplest implementation could just be
open/read/write/stat/close. That would also make it a lot easier to
implement OS extensions on systesm where "everything is a file" [2].

Mike

[1] Of course this assumes you're using symbol versioning (otherwise
you'll get symbol collisions).

[2] Don't care so much about Windows since Windows would just be a stub
implementation into the LSA credential cache.