[krbdev.mit.edu #8764] get_creds can add redundant cache entry for referral ticket

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[krbdev.mit.edu #8764] get_creds can add redundant cache entry for referral ticket

Greg Hudson via RT-2
This is a minor bug.  To reproduce it, change t_referral.py, adding a
line "realm.run(['./gcred', 'srv-hst', 'a/x.d@REFREALM'])" just after
the shutil.copyfile() invocation in testref.  The following three
entries will appear in the klist output before the script fails:

12/12/18 11:28:52  12/13/18 11:28:52  a/x.d@REFREALM
12/12/18 11:28:52  12/13/18 11:28:52  a/x.d@
12/12/18 11:28:52  12/13/18 11:28:52  a/x.d@REFREALM

The first entry was added when we explicitly looked up
a/x.d@REFREALM; the second was added when we asked KRBTEST1.COM for
a/x.d, got a referral, and followed the referral to get a ticket for
a/x.d@REFREALM.  We store that ticket as a/x.d@ (the server principal
asked for by the caller; krb5_cc_store_cred() then stores it again
with the ticket server.

We could:

1. Ignore this problem.  It probably doesn't happen very often and
the consequences aren't severe.  (The cache doesn't grow without
bound or anything, like it did in #8579.)

2. Make get_creds check the cache for a/x@REFREALM before following
the referral TGT.  If we find it, we still need to store as a/x@, but
not as a/x@REFREALM again.  (Currently this is impossible because
krb5_cc_store_cred() performs the double store without being asked;
that logic would have to be pushed upwards.)

3. Make krb5_cc_store_cred() check if there is already a cred for the
ticket server in the cache before doing the second store.

4. Just get rid of the second store operation in krb5_cc_store(),
following the logic of #8579 that there isn't much value in storing
cache entries for things the caller didn't ask for.  If we do this,
we might also want to modify klist to display the ticket server if it
differs from the credential entry server; otherwise there is no way
to see in the klist output what the server realm is for a cacched
referral result.
krb5-bugs mailing list
[hidden email]