Change in K4 ticket cache format
rra at stanford.edu
Mon May 16 20:52:10 EDT 2005
[ Sending this from the correct address -- please feel free to reject the
duplicate in the moderation queue. ]
I *think* this was already discussed here at some point in the past, but I
wanted to bring it up again since I just got bitten by it.
The comments in lib/krb4/tf_util.c about the ticket format have always
* Where "CREDENTIAL_x" consists of the following fixed-length
* fields from the CREDENTIALS structure (see "krb.h"):
* char service[ANAME_SZ]
* char instance[INST_SZ]
* char realm[REALM_SZ]
* C_Block session
* int lifetime
* int kvno
* KTEXT_ST ticket_st
* long issue_date
However, that last data type has been wrong for a long time. If one looks
at krb.h, the definition of the CREDENTIALS struct includes:
KRB4_32 issue_date; /* The issue time */
Now, in the code in lib/krb4/tf_util.c to read the ticket cache, it has
always done the equivalent of:
tf_read((char *) &(issue_date), sizeof(issue_date));
c->issue_date = issue_date;
but in Kerberos v5 1.2.8, issue_date was defined as a KRB4_32, the same as
is specified in krb.h. However, at some point in the 1.3.x series (and
apparently without a mention in the ChangeLog that I can find), the
definition of issue_date in tf_get_cred() and also in tf_save_cred() was
changed from KRB4_32 to a long.
The practical impact of this change is to break ticket file compatibility
with KTH Kerberos on 64-bit platforms, since KTH Kerberos continues to use
an int32_t for the issue date as stored in the ticket cache on disk.
This is largely our fault for not having realized this far, far sooner, as
we've been horribly behind in our local Kerberos installation for quite a
while and not been involved in beta testing.
This problem has now been around for a while, so I'm not sure what
problems would now be caused by switching back. In the abstract, I think
changing the K4 ticket cache format is a very bad idea, even if it gives
better timestamp support on those platforms, since K4 is essentially dead
anyway and really should just be frozen in place. However, the change
already happened a while back and this would be another change to undo it.
It would, however, be really nice to stay compatible with KTH Kerberos, as
that's the best source for an aklog program that works with K4 for those
of us who are still in the process of migrating.
Regardless of what approach is taken, the comment in lib/krb4/tf_util.c
really should be changed, as I bet the code was modified to be consistent
with the comment.
Russ Allbery (rra at stanford.edu) <http://www.eyrie.org/~eagle/>
More information about the krbdev