Sanity check: eliminating mechglue union cred auxinfo field

ghudson@MIT.EDU ghudson at MIT.EDU
Mon Aug 22 11:58:32 EDT 2011

Short form: I want to eliminate the union cred's auxinfo structure and
make gss_inquire_cred query the cred's first mechanism for results.

Long form: since the initial import, our GSS mechglue stores
information about union credentials in a sub-structure named auxinfo.
We initialize the structure everywhere we create a credential
(currently five places) by making gss_inquire_cred calls to the
underlying mechanism.  For gss_acquire_cred/gss_add_cred, we do this
only for the first mechanism we add to the union cred.
gss_inquire_credential is the only consumer of the auxinfo structure,
and uses it rather than querying any underlying mechanisms.

There are several problems here:

1. The auxinfo structure caches a display name, and then imports it
   and canonicalizes it at gss_inquire_cred time.  This is an abuse of
   display names according to my reading of RFC 2743.

2. Asking the mech for information about credentials can force
   deferred credential acquisition to take place inside the mechanism.
   This is particularly undesirable for the credential selection
   project, where we want to defer credential acquisition until the
   gss_init_sec_context() call when possible so that we can select a
   ccache based on the target name.

3. We should be inquiring all of the mechanisms in the union cred and
   aggregating the results: minimum lifetime, maximum cred usage, and
   a name containing one MN for each mech in the union cred.  This is
   unfortunately difficult right now because our union name structure
   can only hold one MN.

4. We repeat a bunch of code to initialize the auxinfo structure in
   all five places we create credentials.  Of course this could be
   solved with a g_glue.c helper without eliminating auxinfo.

I don't propose to solve problem (3).  It's consistent with our
current behavior to just funnel gss_inquire_cred calls to the cred's
first mechanism and convert the resulting name (if present).  I've
implemented this and didn't run into any roadblocks, but I don't need
to commit it immediately.

More information about the krbdev mailing list