Ticket History #8393: Password Expiration "Never" Inconsistently Applied

If you set password expiration to "never" in a policy the result upon creating a principal with that policy is a password expiration with a value of 0 which is interpreted as the beginning of the epoch (1969). If you set the password expiration to "never" via addprinc / modprinc the result is a value of "none" when queried with getprinc. This is inconsistent.

Smaller related issues include:
1. The inconsistency between flags: -pwexpire for addprinc / modprinc versus -maxlife for addpol / modpol.
2. The inconsistency between -pwexpire input of "never" with getprinc output of "none" (what you get out should be identical to what you put in).

The major problem here has to do with how kadmin reads time intervals:
it parses the string as an absolute time using getdate.y and subtracts
the current time. getdate.y supports several date forms relative to
the current time, like "3 days" and you get a natural result if you
input one of these forms. But if you enter a form which is not
relative to the current time, you get nonsensical results:

kadmin.local: addpol -maxlife never testpol2
kadmin.local: getpol testpol
[...]
Maximum password life: 2833951712

kadmin.local: modprinc -maxlife never user
Principal "user@KRBTEST.COM" modified.
kadmin.local: getprinc user
[...]
Maximum ticket life: -16909 days 21:52:08

Given a time machine, we would perhaps make kadmin use libkrb5 str_conv
routines instead of getdate.y, as those functions correctly distinguish
between intervals and absolute times. But that could break many
scripts.

Since we don't have a time machine, we should probably apply some
sanity checks to the get_date() result when reading intervals in
kadmin. If we read an absolute time of 0, we should probably interpret
that as a duration of 0, not 2^32 minus the current Unix time. If we
read a non-zero absolute time which is less than the current time, we
should perhaps yield an error.

Improve kadmin parsing of time intervals

When parsing time intervals in kadmin commands, try
krb5_string_to_deltat() first, then fall back to subtracting the
current time from get_date(). If we do fall back, treat "never" as a
zero interval, and error out rather than yield a huge interval if
get_date() returns a time in the past.

Notable behavior differences: bare numbers of seconds and suffixed
numbers (e.g. "5m" or "6h") are now supported for all intervals;
HH:MM:SS and HH:MM are now treated as intervals rather than absolute
times with the current time subtracted.

https://github.com/krb5/krb5/commit/0e668054974b07ec7ffbe2d9d474062d590c7e69
Author: Greg Hudson <ghudson@mit.edu>
Commit: 0e668054974b07ec7ffbe2d9d474062d590c7e69
Branch: master
doc/admin/admin_commands/kadmin_local.rst | 33 +++++----
src/kadmin/cli/kadmin.c | 117 +++++++++++++++++------------
2 files changed, 86 insertions(+), 64 deletions(-)

Improve kadmin time interval output consistency

Use strdur() to output the maximum and minimum password life for
policies, and output "[never]" instead of "[none]" for a zero password
expiration date for consistency with other dates.

https://github.com/krb5/krb5/commit/7a8e4d3ce6091e806c9ea1049682046635b46e29
Author: Greg Hudson <ghudson@mit.edu>
Commit: 7a8e4d3ce6091e806c9ea1049682046635b46e29
Branch: master
src/kadmin/cli/kadmin.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)