[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exporting gssapi context, take two
Kevin Coffman wrote:
> 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
You may also want to look at linking -Bsymbolic, so any calls from
within a mech lib calls the mech versions.
> Second, the easiest way to implement the glue function is to require
> another parameter for the mechanism. Changing the signature as follows:
> -krb5_gss_set_allowable_enctypes(OM_uint32 *minor_status,
> - gss_cred_id_t cred,
> - OM_uint32 num_ktypes,
> - krb5_enctype *ktypes);
> +gss_set_allowable_enctypes(OM_uint32 *minor_status,
> + gss_cred_id_t cred,
> + gss_OID mechanism,
> + OM_uint32 num_ktypes,
> + void * *ktypes);
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.
> Any suggestions for a cleaner/clearer approach?
> krbdev mailing list firstname.lastname@example.org
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439