On 8/9/2017 2:01 PM, Viktor Dukhovni wrote: > On Wed, Aug 09, 2017 at 07:34:15PM +0200, Harald Barth wrote: > >> Btw, one of my ticket caches looks like this (probably MIT library): >> >> Issued Expires Principal >> Aug 5 18:06:47 2017 Aug 12 18:06:45 2017 >> krbtgt/[email protected] >> Aug 5 18:06:50 2017 >>>Expired<<< >> imap/[email protected] >> Aug 6 18:35:34 2017 >>>Expired<<< >> imap/[email protected] >> Aug 8 09:08:14 2017 >>>Expired<<< >> imap/[email protected] >> Aug 9 09:12:16 2017 Aug 10 09:12:16 2017 >> imap/[email protected] >> >> There is no reason that the expired service tickets are kept around, >> but in this case, the code seems to keep them and append new tickets >> at the end instead. > > By design, the "FILE" credential cache type is *append-only*. Much > fancier read-write locking and recovery would be needed for a cache > where entries can be deleted and replaced. >
I hope this is an unnecessary question, but will all Kerberos libraries that parse the file cache know to skip the expired entries and keep searching? Or are there implementations that will only return the first service principal match?
smime.p7s
Description: S/MIME Cryptographic Signature
