Exporting gssapi context, take two

[Kevin Coffman]

> > I've run into a couple of issues implementing the krb5_gss_set_allowable
> > _enctypes() function.
> > 
> > First, the call to gss_acquire_cred, to get the cred handle, is going
> > through the mechglue layer which returns a handle to the mechglue's
> > union_cred, not a Kerberos cred handle.  This requires a glue function
> > for set_allowable_enctypes() to translate from the union_cred handle to
> > the Kerberos handle.
> 
> Are you saying that the krb5_ specific code is calling gss_acquire_cred?
> It should not have to do this, as internal to the mech the cred should
> be available.   gss_init_sec_context has to do something similiar, so
> look at the code to see how it gets the cred if its not supplied by the
> caller.

The krb5 specific code in my application (gssd) was calling
gss_acquire_cred then krb5_gss_set_allowable_enctypes.
I could call krb5_gss_acquire_cred directly instead (since
I'm already calling a mech-specific routine).  I'll try that.
Is that reasonable?

> If this in needed at the gss level, it should then be part of the
> standard. Then you also have to deal with what how other mechs deal
> with encrypt types.

Yeah, I was trying to avoid this.