[3160] in Kerberos-V5-bugs
Re: krb5-libs/786: Keytab code should cache last-read key
daemon@ATHENA.MIT.EDU (Jonathan Kamens)
Mon Nov 29 14:41:59 1999
Date: Mon, 29 Nov 1999 14:40:44 -0500
From: Jonathan Kamens <jik@kamens.brookline.ma.us>
Message-Id: <199911291940.OAA00393@jik2.kamens.brookline.ma.us>
To: tytso@MIT.EDU
Cc: krb5-bugs@MIT.EDU, krb5-unassigned@rt-11.mit.edu,
gnats-admin@rt-11.mit.edu, krb5-prs@rt-11.mit.edu
In-Reply-To: <199911291925.OAA04240@trampoline.thunk.org> (tytso@MIT.EDU)
> Date: Mon, 29 Nov 1999 14:25:23 -0500
> From: tytso@MIT.EDU
>
> Should there perhaps be a stat() test to see if the keytab has changed,
> or is the assumption that you will kill and restart all application
> daemons when the keytab file is changed?
It doesn't really matter if the keytab has changed, since the caching
I implemented checks the key version number of the cached key. That
is, if a new key is issued for the server, then the tickets issued to
clients will use the new key, and therefore they will not match the
cached key, so the keytab file will be read.
I suppose you could say that a site might bump the version number on
an application server key to lock out clients which snooped an old key
version or something like that, but that seems exceedingly unlikely,
and I don't think protecting against that remote possibility is worth
the additional disk activity of a stat() for every client connection.
jik
