[krbdev.mit.edu #1714] starttime marshalling bug on 64bit platforms in krb524d
Cesar Garcia via RT
rt-comment at krbdev.mit.edu
Thu Aug 7 19:55:51 EDT 2003
Are we looking at the same thing?
===> from lib/krb4/cr_tkt.c:
memcpy(data, session, 8);
data += 8;
*data++ = life;
/* issue time */
KRB4_PUT32BE(data, time_sec);
memcpy(data, sname, snamelen);
data += snamelen;
memcpy(data, sinstance, sinstlen);
data += sinstlen;
====> KRB4_PUT32BE is the relevent macro, from include/kerberosIV/prot.h:
#define KRB4_PUT32BE(p, val) \
do { \
(p)[0] = ((KRB_UINT32)(val) >> 24) & 0xff; \
(p)[1] = ((KRB_UINT32)(val) >> 16) & 0xff; \
(p)[2] = ((KRB_UINT32)(val) >> 8) & 0xff; \
(p)[3] = (KRB_UINT32)(val) & 0xff; \
(p) += 4; \
} while (0)
This is equivalent to casting an 8byte or 4byte quantities (val) to a 4
byte quantity and memcpy'ing the 4 bytes.
If val is big endian, it writes the (casted) 4 bytes as would a
memcpy of 4 bytes, resulting in network byte order (big endian).
If val is little endian, this again, copies bytes as would a
mempcy, resulting in little endian.
With 1.3.1 krb524d running on linux - with code borrowed from libkrb4
as shown above, start time is:
1060266366 (decimal), or
7E61323F (hex, in host byte order, which on my linux box is little
endian).
Would be 3F32617E (hex, if converted to big endian)
These corresponds to: Thu Aug 7 10:26:06 EDT 2003
However, when 7E61323F is interpreted as big endian (212029907 in
decimal), by AFS server, it corresponds to Tue Mar 10 06:57:51 EDT
2037.
AFS error message:
afs: Tokens for user of AFS id 4843 for cell q.ny.ms.com are discarded (rxkad error=19270407)
(don't have code off hand to convert this error code to string).
In any case, this code did not run correctly on linux. When I applied
patch that was submitted, starttime is correctly issued. Without
patch, starttime was postdated and tokens discarded by AFS fileserver.
>>>>> "Tom" == Tom Yu via <RT" <rt-comment at krbdev.mit.edu>> writes:
>>>>> "Cesar" == Cesar Garcia via RT <rt-comment at krbdev.mit.edu> writes:
Cesar> Hmm, not totally. Would appear the code in libkrb4 assumes big
Cesar> endian. (as explained in original mail - code did not work on
Cesar> little endian platforms - e.g., RedHat AS 2.1 on intel, patch
Cesar> addresses this by determining big or little endian and handling
Cesar> accordingly).
Tom> Not exactly... in krb5-1.3, libkrb4 has been modified to
Tom> unconditionally emit big-endian encodings, regardless of the
Tom> endianness of the machine, but will accept either little-endian
Tom> or big-endian.
Tom> ---Tom
More information about the krb5-bugs
mailing list