Sanity check: GSSAPI SPI simplifications
jhutz at cmu.edu
Mon May 24 18:49:44 EDT 2010
--On Friday, April 30, 2010 03:52:44 PM -0500 Nicolas Williams
<Nicolas.Williams at oracle.com> wrote:
>> 1. The mechglue implements gss_acquire_cred in terms of gss_add_cred,
>> and gss_add_cred in terms of mech->gss_acquire_cred. It never invokes
>> As a consequence, there is about 300 lines of orphaned code in the
>> krb5 mech. I propose to get rid of it, and to eliminate gss_add_cred
>> from struct gss_config. (Similarly for gss_add_cred_impersonate_name,
>> which is already nulled out in the krb5 mech.)
> I've noticed this before. Please do eliminate this dead code.
So, this would make the krb5 mech no longer be a GSS-API implementation.
I suppose that's OK, if you assume that your mech is only ever going to be
used with your mechglue. The problem is that as soon as more than one
implementor makes that assumption, you stop being able to use arbitrary
sets of mechanisms -- you can only use sets of mechanisms for which there
is a mechglue with which they are all compatible.
What if I want to use your mechanism, but my OS/application/whatever
already has its own mechglue? What if I am building an application that I
know needs only krb5 and has to run in limited space?
More information about the krbdev