[3284] in Kerberos-V5-bugs
pending/1029: Re: Bug with Kerberos 1.2.2 for 64 bit HPUX 11 !?
daemon@ATHENA.MIT.EDU (Marcus Watts)
Mon Dec 17 23:42:03 2001
Resent-From: gnats@rt-11.mit.edu (GNATS Management)
Resent-To: gnats-admin@rt-11.mit.edu
Resent-Reply-To: krb5-bugs@MIT.EDU, Marcus Watts <mdw@umich.edu>
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>
>Number: 1029
>Category: pending
>Synopsis: Re: Bug with Kerberos 1.2.2 for 64 bit HPUX 11 !?
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Mon Dec 17 23:42:01 EST 2001
>Last-Modified:
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Unformatted:
Jin Zhou <jinz@gene.COM> writes:
> 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
> -----------------------------------
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
