Y2K38 – JAN 19, 2038

So what do I care about some date more than 20 years in the future? Well, let’s start with why this is important:

http://en.wikipedia.org/wiki/Year_2038_problem

Operating systems such as HP-UX keep time by counting the number of seconds since Jan 1, 1970, the birth of Unix. This number is represented as a 32 bit signed integer so the maximum positive value is 2,147,483,647. Add 1 to that number and it becomes a negative number which in most systems will be translated to December 1901.

That should not be an issue, right? Well, it can be a problem right now. Many system administrators pick large numbers for limits that will probably never be met. An example is found in Trusted Systems where you can specify a password lifetime. Rather than pick a specific date in the future, then calculate the number of days, the sysadmin uses 9999, which is about 27 years in the future. Plenty of time, the password will never expire, right?

Seems reasonable. After all, most systems won’t be running 27 years from now. So the sysadmin uses SAM or SMH to set the Trusted System system default password lifetime to 9999, and everything is fine. But the Unix Millenium Bug is alive and well. Today’s time in seconds is:

# perl -le “print time”
1284606642

and 9999 days is 863913600 seconds. So a password expiration check at login, or a pass through all the passwords with modprpw -V will compute the lifetime:

1284606642 (today’s date)
+863913600 (9999 days in the future)
——————–
2148520242 (oops, that’s too large for a 32 bit integer)

So the expiration lifetime is December 1901…AHA! That’s in the past so the password will be expired. You can use SAM, SMH or modprpw to unlock and enable the account, but as soon as the user tries to login, the account is immediately locked with a status of  “exceeded password lifetime“. And as long as the account uses the system default lifetime of 9999 days, that account can never be enabled again.

This bug started this month because 9999 days in the future is 2038, the Millenium Bug date. So what to do? Well, you can set a smaller lifetime as the system default like 8888, but that will be a problem in a couple of years. Use something more reasonable like 4444. That will work for the next decade and most likely the system won’t be Trusted anymore.

Is this a serious problem? Not exactly. It becomes very annoying when all the passwords on all the systems start locking and the fix is to change the default lifetime to a safer value (I’d use 4444 which about 12 years in the future). And as most HP-UX sysadmins know, the Trusted System mechanism will not exist after 11.31. Sysadmins will use Shadow Password and enhanced security for the next major releases

– See more at: http://serviceitdirect.com/blog/y2k38-starting-creep#sthash.LVy1kbAQ.dpuf