get_cred starting realm

[Greg Hudson]

On 04/29/2015 05:54 PM, Greg Hudson wrote:
> On 04/29/2015 02:05 PM, Nico Williams wrote:
>>> * The caller asks for one cred to be stored, but the result is that two
>>> creds are stored, as observed by the cache type and by future iterations.
>>
>> Eh, this already happens, no?  E.g., with the referral realm business.
> 
> Not inside the credential cache layer, no.  Those artifacts are created
> by a higher layer (get_creds).

I was wrong about this; there actually is logic in the generic ccache
store_cred() and retrieve_cred functions for the referral realm.
Apologies for incorrectly contradicting Nico on this point.

I will revise my opinion to: I'm not really happy with solving these
problems inside a layer which was originally designed just to be a
container for credentials and a default client principal.  I think we
have an unfortunate history in MIT krb5 of adding complexity to our
lower-layer contracts in order to solve higher-layer problems.  We
definitely have a history of this in the ccache layer (referrals, config
entries encoded as creds, timestamps), and we have paid costs for that
history.  It may not hurt much to add one more bit of complexity to an
already complex lower layer, but I would like to at least explore other
options.

I think the two other viable options are:

1. Make kinit -n and krb5_gss_accept_sec_context() responsible for
setting a start-realm config entry when the local TGT realm differs from
the client principal realm.  Basically, treat the edge cases as
exceptional and force them to be addressed at the highest possible layers.

2. Ditch the cache config entry, and instead add a new ccache function
to retrieve the main local TGT (which is defined to be the first local
TGT stored in the cache).  Each type would be responsible for
implementing this, either by being order-preserving and just iterating
over the creds until it finds a local TGT, or by remembering which local
TGT was first.

The second option has a pitfall: if a ccache contains multiple local
TGTs (unusual) and is copied using iterate-and-store, and the source
ccache type isn't order-preserving, then the local TGTs might not be
stored in the same order and the wrong one might be treated as the main
TGT.  I don't expect that this problem would occur in practice, but we
might look for a way to solve it at least in krb5_cc_copy_creds() and
krb5_cc_move().