jhutz at cmu.edu
Thu Mar 25 19:56:41 EST 2004
On Thursday, March 25, 2004 19:15:46 -0500 Sam Hartman <hartmans at mit.edu>
> IT seems like gen_new should set up a new ccache. Certainly the fcc
> and mcc implementations do this.
> So to use this API correctly, I think I need to:
> * call krb5_cc_resolv with a bogus residual part to set of a ccache
> structure * save a copy of that ccache structure
> * call krb5_cc_gen_new overwriting the the original ccache structure
> * call krb5_cc_close on my copy of the ccache structure
> That seems nonintuitive at the least and completely broken on top. O
> and since krb5_ccache is opaque, I actually can't even use the API
> without leaking memory.
> Perhaps we should rethink.
It seems like the intent here was to allow a caller to generate a new
ccache of the same type as an existing one, without knowing the type of the
I can think of exactly one situation in which I would want to call such an
interface. Today I have a perl script which sets up a subshell with a new
ccache, initialized with credentials for some alternate principal like
jhutz/root (of course, it runs kinit and I have to provide the password).
It currently makes up a ccache name on its own, based on various factors
designed to produce a unique filename. It would seem desirable for such a
tool to be able to generate a new ccache of the same type as that current
default one, rather than assuming FILE: and constructing its own name.
Besides being broken, I agree that the current behaviour you describe is
nonintuitive -- I'd expect an interface like this to return a new ccache
without clobbering the existing one.
But maybe this isn't even really the best interface. Perhaps it would be
better to have something like
krb5_cc_gen (krb5_context context, char *kind, krb5_ccache *cache)
Then if I want a ccache of the same type as an existing one, I can
krb5_cc_gen(ctx, krb5_cc_get_type(ctx, oldcc), &newcc);
FWIW, in heimdal 0.6 krb5_cc_gen_new is declared this way:
const krb5_cc_ops */*ops*/,
They also have:
const krb5_cc_ops *
Where it looks like krb5_cc_ops is publicly visible (ew).
More information about the krbdev