[477] in Kerberos-V5-bugs
Re: krb5_gen_replay_cache_name outputs char * when krb5_get_server_rcache expects krb5_data
daemon@ATHENA.MIT.EDU (Theodore Ts'o)
Mon May 23 22:47:08 1994
Date: Mon, 23 May 94 22:46:35 EDT
From: tytso@MIT.EDU (Theodore Ts'o)
To: "Jonathan I. Kamens" <jik@security.ov.com>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: "[431] in Kerberos-V5-bugs"
[0431] daemon@ATHENA.MIT.EDU (Jonathan I. Kamens) Kerberos-V5-bugs 03/07/94 15:06 (14 lines)
Date: Mon, 7 Mar 1994 15:06:41 -0500
From: "Jonathan I. Kamens" <jik@security.ov.com>
The "piece" passed into krb5_get_server_rcache to specify part
of the named rcache is supposed to be a krb5_data *. On the other
hand, krb5_gen_replay_name, whose output is supposed to be used as
input to krb5_get_server_rcache, outputs a char *. As far as I can
tell, there's no reason for this inconsistency -- if the output of
gen_replay_name is intended to be used directly as an argument to
get_server_rcache, then either gen_replay_name should output a
krb5_data or get_server_rcache should take a char *.
Your assumption that the output of krb5_gen_replay_name is used as input
to krb5_get_server_rcache is faulty. The output of krb5_gen_replay_name
is a cache tag which can be passed, with a replace cache type prefixed,
to krb5_rc_resolve.
krb5_get_server_rcache takes as input a krb5_data structure, which is
normally krb5_princ_component(server, 1), and returns a resolved replay
cache using the default replay cache type.
These two routines were *not* intended to be used as an output to the
other.
The first is used for times when you want a replay cache which is
specific to a particular client/server association --- that's why
krb5_gen_replay_name takes an address.
The second is used for times when you want a replay cache for all
connections to a particular Kerberos service. This is used in
rd_req_sim.c, for example, since you'd want to you the same replay cache
across all authentication requests --- using a separate replay cache for
each separate client host would completely miss the point. :-)
- Ted