Handle the case where the system date is changed back before lst_chg.
Previously one could not change a password, getting "you needed to wait longer".
An easy way to trigger this is to install linux on a box with a bad date
(in the future). This will cause all the shadow entries to have lst_chg
fields in the future, when the date is set correctly (the user is only
prompted to set the date at firstboot in fedora at least).
Note fedora at least defaults the min field to 0 rather than -1,
but logically 0 should mean the same thing (and it does with this patch).
This patch also aligns with what is done in pam_unix_acct.c.

diff -Naur -Naru Linux-PAM-0.80/modules/pam_unix/pam_unix_passwd.c Linux-PAM-0.80-pb/modules/pam_unix/pam_unix_passwd.c
--- Linux-PAM-0.80/modules/pam_unix/pam_unix_passwd.c	2005-06-09 17:24:26.000000000 +0000
+++ Linux-PAM-0.80-pb/modules/pam_unix/pam_unix_passwd.c	2005-07-26 18:13:46.000000000 +0000
@@ -920,8 +920,12 @@
 		if (off(UNIX__IAMROOT, ctrl)) {
 			/* Get the current number of days since 1970 */
 			curdays = time(NULL) / (60 * 60 * 24);
-			if ((curdays < (spwdent->sp_lstchg + spwdent->sp_min))
-			    && (spwdent->sp_min != -1))
+			if (curdays < spwdent->sp_lstchg)
+				_log_err(LOG_DEBUG, pamh
+				 ,"account %s has password changed in future"
+				 ,user);
+			else if ((curdays < (spwdent->sp_lstchg + spwdent->sp_min))
+				 && (spwdent->sp_min != -1))
 				retval = PAM_AUTHTOK_ERR;
 			else if ((curdays > (spwdent->sp_lstchg + spwdent->sp_max + spwdent->sp_inact))
 				 && (spwdent->sp_max != -1) && (spwdent->sp_inact != -1)