Problem with kerberos and ssh.

[Nicolas Williams]

On Mon, Feb 27, 2006 at 03:35:12PM +0000, Jeffrey Altman wrote:
> Eric wrote:
> > 
> >     I have reached the conclusion that this is an ssh bug and not a
> > kerberos bug or configuration problem.
> > 
> >     Essentially the problem was that ssh is calling
> > 
> >    ctx->major = gss_accept_sec_context(&ctx->minor,
> >        &ctx->context, ctx->creds, recv_tok,
> >        GSS_C_NO_CHANNEL_BINDINGS, &ctx->client, &mech,
> >        send_tok, flags, NULL, &ctx->client_creds);
> > 
> > and saving off ctx->client for later use.  Under the hood, ctx->client
> > is simply a gss_union_name_t.

As far as the ssh code is concerned it can ONLY be a gss_name_t, an
opaque type.

The GSS-API library might have a concept of gss_union_name_t (Solaris'
does), and may track a mechanism-specific type opaquely (which might be,
say, krb5_principal, or whatever, this being up to the mechanism).  Or
it might be a monolythic one-mechanism implementation, in which case
what is a gss_name_t to the app might be a krb5_principal (or whatever)
to the library.

But as far as the app's concerned this can only be a gss_name_t, and
that is an opaque type (it might be a void *, a pointer to an incomplete
struct, an integer index to a table -- the app doesn't and shouldn't
know which).

> > Later on, ssh calls
> > 
> >         if ((ctx->major = gss_export_name(&ctx->minor, ctx->client,
> >             &ename))) {
> >                 ssh_gssapi_error(ctx);
> >                 return (ctx->major);
> >         }
> > 
> > Here ctx->client is passed in and gss_export_name assumes that the input
> > name is a krb5_principal.  Not surprisingly, the datatype mismatch
> > causes the call to fail.  Could have caused it to crash, I suppose -
> > that would have been a much clearer indication of what the trouble was.

Sounds like a bug in the GSS-API library.  Is this the MIT gss library?

Nico
--