Problem with kerberos and ssh.

[Wyllys Ingersoll]

Eric wrote:
>  Jeffrey Altman wrote:
> > What is gss_union_name_t defined as?   This is not a GSS type.
> >
> > gss_accept_sec_context() exports a gss_name_t object and
> > gss_export_name() takes a gss_name_t as input.  gss_name_t when
> > produced by a krb5 gss mechanism will be a krb5_principal.
> > However, gss_name_t is not required be a krb5_principal.
>
>  It appears to be a type internally used by gss, and it is created
>  directly by gss_accept_sec_context().  I found the structure
>  definitions in:
>
>  krb5-1.4.3/src/lib/gssapi/mechglue/mglueP.h
>
>  and also in:
>
>  libgssapi-0.7/src/mglueP.h

Either way, those are private headers and are not intended to be used by 
applications.
(The "P" at the end is a hint that it is private and not a public 
interface).


>
>  the odd thing is that the two definitions are substantively
>  different. THe one from krb5-1.4.3 looks like:

I think they are allowed to be different as long as they are not exposed 
as part of the API.
Your application should not need to be referencing any 
"gss_union_name_t" types,
it should only be concerned with "gss_name_t".


[...]
>
>
>  ==============================
>
>  It is the thing at the end - __gss_convert_name_to_union_name that
>  creates the thing that is passed out of gss_accept_sec_context().
>
>  It may well be true that a gss_name_t isn't required to be a
>  krb5_principal.  I have also posted to the openssh mailing list -
>  people who know the code a lot better can take what I have discovered
>  and do a better job of figuring out where things are really going
>  wrong.

Its definitely true that gss_name_t is not required to be a kerberos 
principal.   GSS is
intended to be an abstraction.  The calling application should never 
assume details
about the underlying mechanisms or the actual structure of things that are
purposely defined as opaque.



-Wyllys