Received: from pivsbh2.ms.com (pivsbh2.ms.com [199.89.64.104]) by krbdev.mit.edu (8.9.3) with ESMTP id TAA14654; Thu, 7 Aug 2003 19:55:49 -0400 (EDT) Received: from pivsbh2.ms.com (localhost [127.0.0.1]) by localhost.ms.com (Postfix) with SMTP id CDB87F6A4; Thu, 7 Aug 2003 19:55:48 -0400 (EDT) Received: from ny16im02.ms.com (unknown [144.14.206.243]) by pivsbh2.ms.com (internal Postfix) with ESMTP id ADF5011808; Thu, 7 Aug 2003 19:55:48 -0400 (EDT) Received: from limus.ms.com (limus [144.14.15.176]) by ny16im02.ms.com (Sendmail MTA Hub) with ESMTP id h77NtmT09974; Thu, 7 Aug 2003 19:55:48 -0400 (EDT) Received: (cesarg@localhost) by limus.ms.com (8.11.6/sendmail.cf.client v1.05) id h77NtmG12380; Thu, 7 Aug 2003 19:55:48 -0400 X-Mailer: 21.4 (patch 12) "Portable Code" XEmacs Lucid (via feedmail 10 I); VM 7.14 under 21.4 (patch 12) "Portable Code" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16178.59139.954652.810683@limus.ms.com> Date: Thu, 7 Aug 2003 19:55:47 -0400 From: Cesar Garcia To: rt-comment@krbdev.mit.edu Cc: Cesar.Garcia@morganstanley.com, krb5-prs@mit.edu Subject: Re: [krbdev.mit.edu #1714] starttime marshalling bug on 64bit platforms in krb524d In-Reply-To: References: RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 2624 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 > writes: >>>>> "Cesar" == Cesar Garcia via RT 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