[2260] in Kerberos-V5-bugs
Re: maxlife (was Re: Bug fix: kdc.conf not being read)
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Mon Sep 23 16:51:11 1996
Date: Mon, 23 Sep 1996 16:48:15 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: roma@uiuc.edu
Cc: krb5-bugs@MIT.EDU, kerberos@MIT.EDU
In-Reply-To: <199609231752.MAA35892@zippy.cso.uiuc.edu> (message from Jon Roma
on Mon, 23 Sep 1996 12:52:49 -0500)
-maxlife 10h generated a positive maxlife result, where the
-maxlife "10 h" lifetime seems to be the amount of time
remaining to the top of the next hour!
This one caught me by surprise, as I didn't think "h" would work at
all. Reading the sources reveals that getdate supports "military time
zones," a-z for 1 to 12, -1 to -12, and 0; for those trivia buffs out
there, the letter j does not seem to be used (anyone know why?).
This reveals the basic problem with using getdate: it supports such a
variety of time/date formats, most of them useless and confusing, that
the end result is chaos---you never really know how a string is going
to be parsed. We have discussed ditching getdate for all relative
time specs (like max_life) in kadmin and using instead the same parser
that handles the "10h 30m"-like spec (although it will have to
extended to handle weeks, months, and years), and then using a
scaled-down getdate that does not allow any relative specs for the
absolute time specs (like principal expiration). But we haven't come
to a conclusion yet.
Barry
