I got bamboozled by several factors working in unison here. One of them
probably has something to do with a certain admin not bothering to change a
good password for a while.
The /etc/auth/system/default file has a u_life parameter that specifies the
lifetime (in seconds) of a password. It's default value is one year. If the
current ctime value - u_succhg is >= the u_life field, your account gets
locked, assuming u_life > 0.
The last recorded password change for the root account was exactly one year
ago. (I'm of the mind that if a password is good -- can't be cracked, and
can't be guessed, or otherwise obtained... why change it).
BTW, here's a little C program I whipped up to convert all those numbers to
date format:
#include <stdio.h>
#include <time.h>
main(int argc,char **argv)
{
time_t value = atoi(argv[1]);
printf("The ctime value for %ld is %s\n",value,ctime(&value));
};
I'd love to rant about how big a mistake it is to let the only account that
can fix this problem be nailed by it, but that's what singleuser mode is for
I guess. (Let's not even mention proper setup of the C2 configuration and/or
password changes on a less-than-yearly basis.)
(I've also found that the only way to virtually ENSURE finding the answer in
a timely fashion is to send mail to a whole buncha people; either they give
you the answer first, or you realize you just made a fool of yourself)
---
Mike Matthews, Mike_Matthews_at_sgate.com (NeXTmail accepted)
PGP public key available on request
Received on Thu Sep 19 1996 - 00:32:36 NZST