Change in K4 ticket cache format

[Jeffrey Hutzelman]

On Thursday, October 27, 2005 09:18:57 PM -0400 "Alejandro R. Sedeno" 
<asedeno at mit.edu> wrote:

> A little progress report and some questions.
>
> I've put some thought into the big-endian system alignment records and
> came up with some. I'd appreciate it if someone would look over them as
> a sanity check. They're available at:
>
> /afs/athena.mit.edu/user/a/s/asedeno/Public/krb4-big.txt
>
> or
>
> http://web.mit.edu/asedeno/Public/krb4-big.txt
>
> The quick summary is that there are four records, for the case of an
> issue_date with 0-3 NULL bytes in it. I'm assuming the MSB will never
> again be NULL. By the time this assumption becomes false, krb4 should be
> long buried, and besides the field is too small to deal.
>
> So my questions are:
>
> Is there a recommended way for checking byte order? I can implement a
> runtime check, but if there's a proper/preferred way to do it at compile
> time I'd rather do it that way.

I should think a krb4 library would already know the local byte order, 
since you need to know that in order to handle the "sender's choice" byte 
ordering used in the krb4 protocol.  Lacking that, I believe there is an 
autoconf test for this.


> Should I care about catching the case in which there are three NULLs in
> issue_date? This will only happen once every 6.37 months for a second,
> and it seems like a waste to check for it.

My first instinct is to go ahead and check for it, on the grounds that
completeness is nice.  Of course, when I was looking at your stuff before,
it hadn't occurred to me that you could assume the MSB would always be 
non-null, which does simplify this problem somewhat.

Maybe in the three-nulls case, you could write out an issue_date one
second earlier than the real one, which would eliminate the need for a
separate alignment record for that case, improve compatibility with other
implementations (which, after all, is the point of the exercise), and
shouldn't cause any new problems.


> Should writing out the alignment record be run-time configurable, and
> what should the default behavior be?

I think the default behavior should be to always write out the records.
When I did the LSB-first version of this, I was assuming that the majority 
of Kerberized applications in use would be running my code, but that from 
time to time users would run old binaries or those provided by another 
source.  The point of the alignment records was to allow for those cases, 
which are usually pretty un-predictable.

Unfortunately, krb4 doesn't really have a general-purpose configuration 
file which can be used to control behavior like this.  In situations where 
it is considered acceptable for the krb4 library to process krb5.conf 
(MacOS?), it might be appropriate to provide a confiugration option to 
disable writing of alignment records.  However, the new code should always 
be able to read ticket files containing a mixture(*) of 32-bit-issue_date 
and 64-bit-issue_date records, regardless of configuration.



(*) Yes, you need to be able to read a mixture.  While the alignment 
records insure that both 32-bit and 64-bit legacy libraries will be able to 
read the file, those libraries will always _write_ their favorite form, 
without an alignment record.  This is pretty common, as an application is 
likely to read a TGT, obtain a service ticket, and append it to the file. 
Once a legacy application has appended a ticket to a ticket file, any later 
tickets will not be readable by legacy applications with the other word 
size (this generally means those applications will not be able to get and 
use new service tickets, since that involves writing the new ticket to the 
end of the file and then reading it back).

The only way to recover from this situation is to have tools which can read 
a mixture of tickets in either format, with and without alignment records, 
and write them back out in a uniform format.  I have a program, kfixtickets 
(see /afs/cs.cmu.edu/misc/aaa/src/aaa-head/bin/kfixtickets.c), which does 
this using the normal tf_* library interfaces.


-- Jeff