I've noticed that if one's ccache is truncated in the wrong way
that some applications will core dump on some OSes because of a
double free.  (Of course a double free has undefined behaviour and
hence a core dump conforms to the spec.)

I attach a one line patch that removes the double free, but one is
still left with a ccache to which additional tickets cannot be
added.  Or at least, they are added but since they are simply
appended they are in the wrong place.  In the best case they are
ignored but I am convinced that there will be degenerate cases
where e.g. malloc() will be called with ridiculous arguments, etc.
I think that the code which adds tickets to ccaches should not
simply append the tickets but rather find the offset of the last
valid ticket seek() to it, ftruncate() the file and then append
the ticket.

Now, as for how we ended up with a truncated ccache---I don't know,
but a process was probably killed at an inappropriate time or some
such.

--
    Roland Dowdeswell                      http://www.Imrryr.ORG/~elric/

sasas1 $ cvs diff -ur1.1 -r1.2 cc_file.c
Index: cc_file.c
===================================================================
RCS file: /ms/dev/kerberos/mitkrb5/cvs-dirs/mitkrb5-1.4/mitkrb5/src/lib/krb5/ccache/cc_file.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -u -r1.1 -r1.2
--- cc_file.c   28 Mar 2005 21:43:34 -0000      1.1
+++ cc_file.c   21 Jun 2005 19:00:13 -0000      1.2
@@ -636,6 +636,7 @@
  errout:
      if (data->data)
 	 krb5_xfree(data->data);
+     data->data = NULL;
      return kret;
 }