[16501] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: X-CACHECONF in cache type 0504

daemon@ATHENA.MIT.EDU (Tim Alsop)
Sat Nov 20 23:04:32 2010

From: Tim Alsop <Tim@cybersafe.com>
To: Greg Hudson <ghudson@mit.edu>, Tim Alsop <Tim@cybersafe.com>
Date: Fri, 19 Nov 2010 22:18:18 +0000
Message-ID: <C90CA807.27AA7%Tim.Alsop@CyberSafe.com>
In-Reply-To: <1290195915.2633.1280.camel@ray>
Content-Language: en-US
MIME-Version: 1.0
Cc: "krbdev@MIT.EDU" <krbdev@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

Greg,

Thankyou for your help. I think I have all I need now.

Take care,
Tim

On 19/11/2010 19:45, "Greg Hudson" <ghudson@mit.edu> wrote:

>On Fri, 2010-11-19 at 10:54 -0500, Tim Alsop wrote:
>> Thanks. I guess, what I need to know is, do we need to store our own
>> configuration data with krb5_ccache_conf_data as the name and
>>X-CACHECONF
>> as the realm ?
>
>If you want the MIT and Heimdal klist to ignore those entries, yes.  (If
>by "the name" you mean "the first component of the principal".)
>
>>  It seems that the name krb5_ccache_conf_data is referring
>> to a function name in the MIT/Heimdal code ?
>
>No, it's just a well-known string.  There's no function by that name.
>
>>  We do not have a function
>> with this name in our code, and do not plan to add such a function, so
>>if
>> we use different name in cache to store configuration data, will this
>> break interoperability ?
>
>If you used a different first component, it would break interoperability
>in the sense that recent MIT/Heimdal klist would show those config
>entries, and the MIT/Heimdal krb5_cc_get_config/krb5_cc_set_config APIs
>would be unable to operate on your entries.
>
>


_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post