Ticket History #1028: Bug with Kerberos 1.2.2 for 64 bit HPUX 11 !?

From jinz@gene.COM Mon Dec 17 23:19:58 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id XAA23301
for <bugs@RT-11.mit.edu>; Mon, 17 Dec 2001 23:19:57 -0500 (EST)
Received: from genie.gene.com (genie-open.gene.com [192.12.78.1])
by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id XAA26183;
Mon, 17 Dec 2001 23:02:15 -0500 (EST)
Received: from larned.gene.com (larned.gene.com [128.137.49.7])
by genie.gene.com (8.11.0/8.11.0) with ESMTP id fBI42E6278589;
Mon, 17 Dec 2001 20:02:14 -0800 (PST)
Received: from gene.com (dhcp194-165.gene.com [128.137.194.165])
by larned.gene.com (8.11.3/8.11.3) with ESMTP id fBI42DW1056106;
Mon, 17 Dec 2001 20:02:14 -0800 (PST)
Message-Id: <3C1EBF7E.A9C0A89B@gene.com>
Date: Mon, 17 Dec 2001 20:01:02 -0800
From: Jin Zhou <jinz@gene.COM>
To: kerberos@mit.edu, krb5-bugs@mit.edu
Subject: Bug with Kerberos 1.2.2 for 64 bit HPUX 11 !?

Hi:

I compiled Kerberos 1.2.2 on HPUX 11.00 with "+DD64" flag passed to
cc compiler, which means all
the binaries will be in 64 bit format.

Everything so far works fine except for /usr/local/sbin/kadmin. Here
is what happens when I run kadmin
trying to connect to a kadmind & krb5kdc running on another Unix box:
%
% /usr/local/sbin/kadmin
Authenticating as principal user1/admin@TEST.COM with password.
Enter password:
kadmin: GSS-API (or Kerberos) error while initializing kadmin
interface
%

In KDC's /var/log/kadmin.log file, I can see that (xxx is the
machine's IP address):
kadmind[4342](Notice): Authentication attempt failed: xxx.xxx.xxx.xxx,
GSS-API error strings are:
kadmind[4342](Notice): A token was invalid
kadmind[4342](Notice): Token header is malformed or corrupt
kadmind[4342](Notice): GSS-API error strings complet

I did some troubleshootings, finally the problem being traced back
to system call "clnt_call()" around line #287 in
./Kerberos/src/lib/rpc/auth_gssapi.c where "call_res" gets its value by
calling "clnt_call()". The program exit around line #329 when the value
of "call_res.gss_major" is checked and found invalid.

The interesting part is that I'm not sure whether this is a bug in
HPUX 11 64 bit RPC library or a bug with Kerberos 122. Because
clnt_call() actually returns "RPC_SUCCESS" as exit code, but yet gets
invalid value for "call_res.gss_major".

Can somebody who runs 64 bit Kerberos on HPUX 11 test whether kadmin
works or not ? My KDC has no problem, because we can run kadmin from
other (SGI, SUN, HPUX10.20) Kerberos systems without any problem.

If this is a bug, then just treat my message a bug report.

Thanks

Jin
-----------------------------------

From mdw@umich.edu Mon Dec 17 23:41:49 2001
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76])
by rt-11.mit.edu (8.9.3/8.9.3) with ESMTP id XAA23359
for <bugs@RT-11.mit.edu>; Mon, 17 Dec 2001 23:41:49 -0500 (EST)
Received: from quince.ifs.umich.edu (quince.ifs.umich.edu [141.213.229.138])
by fort-point-station.mit.edu (8.9.2/8.9.2) with SMTP id XAA03032;
Mon, 17 Dec 2001 23:41:12 -0500 (EST)
Received: from pepper-pot (pepper-pot.ifs.umich.edu [141.213.229.91]) by quince.ifs.umich.edu (8.6.13/8.6.12) with ESMTP id XAA10816; Mon, 17 Dec 2001 23:40:59 -0500
Message-Id: <200112180440.XAA10816@quince.ifs.umich.edu>
Date: Mon, 17 Dec 2001 23:40:59 -0500
From: Marcus Watts <mdw@umich.edu>
To: Jin Zhou <jinz@gene.COM>
Cc: kerberos@mit.edu, krb5-bugs@mit.edu, mdw@quince.ifs.umich.edu
In-Reply-To: Your message of "Mon, 17 Dec 2001 20:01:02 PST."
<3C1EBF7E.A9C0A89B@gene.com>
Subject: Re: Bug with Kerberos 1.2.2 for 64 bit HPUX 11 !?

Jin Zhou <jinz@gene.COM> writes:

Most likely, your client is generating defective data, which the
server is detecting, then returning an error. The client side error
message "GSS-API (or Kerberos) error while initializing kadmin" is
pretty much the catch-all, means little in itself (except that you
are in for much drudgery). All of this is below the RPC code,
in the gssapi layer of things, so you probably shouldn't need
to worry about what clnt_call is thinking. At least in theory.

The server side errors are actually more useful. Those errors
probably actually come from kadmind not from kdc. The useful
manifests are
GSS_S_DEFECTIVE_TOKEN = A token was invalid
G_BAD_TOK_HEADER = Token header is malformed or corrupt
Mapping the "useful" english text that gssapi prints out,
to the actual manifests in the code, is one of the challenges
that this code presents.

G_BAD_TOK_HEADER can only be generated by the routine
g_verify_token_header in lib/gssapi/generic/util_token.c .
You'll probably have to step through kadmind, dump out the data
as it passes through this routine, and compare it with a "good" kadmind
run from a connection with a 32-bit client to to see what's wrong. Probably
there is some sort of 64-bitness that caused the client to generate bad
data... You may also need to step through the client side that is
generating this code, and compare that as well.

-Marcus Watts
UM ITCS Umich Systems Group