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/besserwisser....@besserwisser.org
>> Aug  5 18:06:50 2017  >>>Expired<<<         
>> imap/jaja.besserwisser....@besserwisser.org
>> Aug  6 18:35:34 2017  >>>Expired<<<         
>> imap/jaja.besserwisser....@besserwisser.org
>> Aug  8 09:08:14 2017  >>>Expired<<<         
>> imap/jaja.besserwisser....@besserwisser.org
>> Aug  9 09:12:16 2017  Aug 10 09:12:16 2017  
>> imap/jaja.besserwisser....@besserwisser.org
>>
>> 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?



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to