[ Moved to tech-userlevel@netbsd.org ]

On Thu, Aug 10, 2000 at 04:11:27PM +0200, Johan Danielsson wrote:

 > This is quite broken.
 > 
 > If you do
 > 
 >         krb5_cc_resolve(context, "MEMORY:foo", &id1);
 >         krb5_cc_resolve(context, "MEMORY:foo", &id2);
 >         krb5_cc_destroy(context, id1);
 > 
 > id2 points to free'd data.

Okay, I'll take a look at what happens with that code block in the
MIT case.  Looks like the same thing happens (points to freed data)
in the MIT case, as well.

And, actually, looking a little closer, cc_close and cc_destroy seem
to have different semantics in Heimdal than in MIT krb5.

In Heimdal, cc_close does what cc_destroy does in MIT.  This seems
wrong.  I think cc_close is meant to be able to be used like:

	krb5_cc_resolve(context, "MEMORY:foo", &id1);
	krb5_cc_resolve(context, "MEMORY:foo", &id2);
	krb5_cc_close(context, id1);

...and id2 is still valid.

Looks like cc_close is "free resources associated with my instance
of the CC ID", and cc_destroy is "delete this CC ID completely".

So, for the MCC, looks like cc_close should be a noop, cc_destroy should
fully tear down everything, and there should be no reference counting.

 > Furthermore it creates files in /tmp, which is not really desirable.

This is to prevent name clashes in the gen_new case.  Certainly, some
other method could be used to ensure unique MCC names, but this also
happens to be the way MIT did it.  I'll look at changing this, if you
think it's really that important.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>