MSLSA and ccconfigs (Re: get_cred starting realm)

[Benjamin Kaduk]

On Wed, 29 Apr 2015, Nico Williams wrote:

> On Wed, Apr 29, 2015 at 06:24:07PM -0400, Benjamin Kaduk wrote:
> > On Wed, 29 Apr 2015, Nico Williams wrote:
> >
> > > > The LSA itself permits insertion; our MSLSA interface to it may not be
> > > > quite so generous, though I don't remember offhand.
> > >
> > > Does it permit storing of ccconfigs?  (That would be handy.)
> >
> >    2060     if (krb5_is_config_principal(context, creds->server)) {
> >    2061         /* mslsa cannot store config creds, so we have to bail.
> >    2062          * The 'right' thing to do would be to return an appropriate error,
> >    2063          * but that would require modifying the calling code to check
> >    2064          * for that error and ignore it.
> >    2065          */
> >    2066         return KRB5_OK;
> >    2067     }
> >
> > Though, I expect that code was written ten or fifteen years ago and the
> > comment may be stale.
>
> Unless the LSA blows up (it shouldn't) or kills the caller (it
> shouldn't), what's the point of stubbing this out?  Just try it.  In the
> worst case scenario it fails.

The "real" operation corresponding logically to storing an extant ticket
into the LSA is KerbSubmitTicket(), called next after this, but if that
fails, we attempt to coerce the LSA into retrieving a corresponding ticket
on our behalf; I expect this latter step would behave poorly (probably
hanging for a DNS timeout) for config entries.

That said, I don't see an issue with moving the config check after
KerbSubmitTicket() (but before GetMSCacheTicketFromMITCred()).

The check for config principals was added in December 2011, possibly
because that was the first time work was done on KfW since config entries
had been added to the tree.  I don't know how much testing of various
cases was done prior to that commit
(0d2e965bb94fe7df11104fa462104f4eb19086a3).

-Ben