[26946] in Athena Bugs
Re: 9.4.26 sun: Strange krb4 expiry problems
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Sep 5 13:50:37 2006
From: Greg Hudson <ghudson@mit.edu>
To: John Hawkinson <jhawk@mit.edu>
In-Reply-To: <20060905174023.GE8311@multics.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 05 Sep 2006 13:50:17 -0400
Message-Id: <1157478618.346.6.camel@equal-rites.mit.edu>
Mime-Version: 1.0
X-Spam-Score: 1.218
X-Spam-Level: * (1.218)
X-Spam-Flag: NO
Cc: bugs@mit.edu
Errors-To: bugs-bounces@mit.edu
On Tue, 2006-09-05 at 13:40 -0400, John Hawkinson wrote:
> Since the overhead of ticket renewal is low, I think the better workaround
> is the one that produces the least confusion, which is to renew
> tickets every 7 hours. Then you never get in the situation where
> klist is "lying" to you, etc.
You're probably right. For me that's not the best workaround since I'm
renewing tickets manually at the moment, but since you're using a script
it's probably better for you.
I believe the reporting path is to file a ticket with network@mit.edu.
I am not sure this problem can be addressed in the near term, since
there is no conservative fix. Introducing the CMU algorithm into the
krb5kdc code base they're using is probably too big of a change, and I
don't know when they plan to consider upgrading to a newer version of
the code.
Incidentally, a related issue I noticed is that if you make an initial
krb4 krbtgt request--that's with no involvement from krb524d--with a
lifetime of 141 (22 hours under the CMU algorithm), you are handed back
a krbtgt with a lifetime of 255 for some reason. As a result, you don't
run into the early-expiry problem so much when you make an initial
long-life ticket request without using krb524d, although because krb5kdc
isn't using the CMU algorithm, the month-long-CMU-wise krb4 krbtgt you
receive may decay into a 22-hour krbtgt if you use it to obtain service
tickets later on.
