On Wed, Aug 09, 2017 at 06:34:27PM +0000, Viktor Dukhovni wrote: > On Wed, Aug 09, 2017 at 01:11:07PM -0500, Nico Williams wrote: > > On Wed, Aug 09, 2017 at 06:01:26PM +0000, 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. > > > > Actually, no, the FILE ccache does support deletion, certainly in > > Heimdal 7.x. > > That's in-place invalidation, not deletion. I was talking about > deletion.
Well, OK, but I'd call it logical deletion (I don't recall if we made klist hide such entries, but if not we should). Logical deletion is sufficient when it comes to making sure that we fetch a new service ticket. Actually, it's not even necessary, and I do believe the library in 7.x will fetch a new ticket if there's only an expired one in the ccache and an unexpired TGT is available. Shifting subsequent entries over to *really* delete the old entry is simply not possible with the new locking regimen. Reusing logically-deleted slots is doable but tricky. If the issue is ccache size, then one can always just reinitialize. And we should definitely consider doing that in krb5_get_credentials() and friends to keep the ccache to a reasonable size. We do need to re-think re-initialization in the new locking regimen -- re-init via truncation probably works well enough right now, but mostly by accident. Nico --
