On 2017-11-07 11:21:45, Roland C. Dowdeswell wrote: > On Tue, Nov 07, 2017 at 10:55:08AM +0100, Patrik Lundin wrote: > > > > > Additionally, I see that the prune code basically figures out the most > > recent keyset timestamp that is older than the ticket maximum lifetime and > > then removes all keysets with a timestamp older than that one. This > > means that this too old but most recent keyset will be kept, but since > > it was calculated to be older than max-lifetime, shouldnt it be removed > > as well? As it stands now there will always remain at least one keyset > > (depending on if there are more than one keyset with the same timestamp) > > too old to be useful. > > > > Would it make sense to alter the code to also remove that most recent > > (but too old) keyset? The only functional difference of the diff below > > is the "<" to "<=" change at the bottom, but it felt like it would > > warrant a more fitting variable name as well: > > It isn't too old, however. What we are trying to achieve here is > that we keep all of the keys which might have outstanding tickets in > someone's ccache. >
Ah, I was confused by the "get" calls censoring the returned entries. I was under the impression hdb_prune_keys() actually modified the database, I understand now that it only acts as a filter and the actual modification of the database is performed separately when a new key is set. It makes sense to leave at least one trailing keyset if they are only trimmed in conjunction with the principal getting a new key. Sorry for the confusion on the list! -- Patrik Lundin
