if system date is set to 01-01-1970 users are enforced to update their password

I've been looking into this bug, and the problem comes from how adduser (which calls useradd) places an account into /etc/shadow. Based on the default options, here is what a test account from /etc/shadow looks like

test:$6$34MquWg3$Nar6/FMoE6Aj3AgcpNgbPQq.Ww2CowvAWeujm7qt9AdqskPtrLj3we4hYw8JsGSA6KN3t4dhlTL4uJmxi9RuJ/:0:0:99999:7:::

Breaking this down, this account has the following settings

Username: test
Encrypted Password (which is test): $6$34MquWg3$Nar6/FMoE6Aj3AgcpNgbPQq.Ww2CowvAWeujm7qt9AdqskPtrLj3we4hYw8JsGSA6KN3t4dhlTL4uJmxi9RuJ/
Days since epoch that the password was last changed: 0
Days before password may be changed: 0
Days after which a password must be changed: 99999 (libshadow considers this infinite)
Days before password is to expire that user is warned: 7
Days after password expires that account is disabled: NULL
Days since epcoh that account is disabled: NULL

According to the source code, for an account that should not be disabled should have the last and max fields blank, and not zero:

Relevant sourcecode:
 /*
  * The last and max fields must be present for an account
  * to have an expired password. A maximum of >10000 days
  * is considered to be infinite.
  */

 if (sp->sp_lstchg == -1 ||
     sp->sp_max == -1 || sp->sp_max >= (10000L * DAY / SCALE))
  return 0;

(just to ease any confusion, a blank field is returned -1).

Changing the test shadow line to:
test:$6$34MquWg3$Nar6/FMoE6Aj3AgcpNgbPQq.Ww2CowvAWeujm7qt9AdqskPtrLj3we4hYw8JsGSA6KN3t4dhlTL4uJmxi9RuJ/:::99999:7:::

allows successful login.

Running a few tests, and poking adduser's source reveals the problem is with useradd. useradd has a command line switch for setting an expiration date, but by default, generates a shadow line that looks like this:

test2:!:0:0:99999:7:::

So in the end, its a bug in useradd, it simply should omit the field vs. placing a zero in it.

Here's a potential fix. Here's the changelog

  * debian/patches/593_omit_lastchange_field_if_clock_is_misset (LP: #349504)
    - If the system clock is set to Jan 01, 1970, and a new user is created
      the last changed field gets set to 0, which tells login that the
      password is expired and must be changed. During installation,
      this can cause autologin to fail. Having the clock set to 01/01/1970
      on a fresh install is common on the ARM architecture, so this is a high
      priority bug since its likely to affect most ARM users on first install

Colin, your comments?

Trivial comments first: there's a duplicate patch file in the debdiff; it looks like the patch isn't consistently using the same tab/space conventions as the original source.

I checked glibc, and it does indeed consistently interpret an empty sp_lstchg field as -1.

I checked PAM (modules/pam_unix/passverify.c). It doesn't do anything special with sp_lstchg == -1; instead it's just as if you'd set a last changed date of 31 December 1969. Arguably this is a bug in PAM. That said, with a 99999-day expiry, we'll very probably all be dead before it matters.

Do you think we need to do anything with any of the other tools in shadow? shadow gets the time in several independent places. I'm perfectly happy for the answer to be "no", as long as we've thought about it.

Here's a revised debdiff that corrects all the issues as well as makes the change in all parts of shadow (and properly displays the warning).

w.r.t. to pam and the expiration date, maybe we should also properly disable those fields and have no default set (I have a patch that fixes that by commenting out the relevant config lines in /etc/login.defs).

I guess the last remaining question is there anything beside shadow we need to care about?

I think the proper place to fix PAM's sp_lstchg handling bug is in PAM. Nevertheless, it's not urgent and can be left until later. I'd rather make minimal necessary changes to shadow at this point.

I can't think of anything else besides shadow.

Uploaded, thanks!

This bug was fixed in the package shadow - 1:4.1.1-6ubuntu4

---------------
shadow (1:4.1.1-6ubuntu4) jaunty; urgency=low

  * debian/patches/593_omit_lastchange_field_if_clock_is_misset (LP: #349504)
    - If the system clock is set to Jan 01, 1970, and a new user is created
      the last changed field gets set to 0, which tells login that the
      password is expired and must be changed. During installation,
      this can cause autologin to fail. Having the clock set to 01/01/1970
      on a fresh install is common on the ARM architecture, so this is a high
      priority bug since its likely to affect most ARM users on first install

 -- Michael Casadevall <email address hidden> Thu, 02 Apr 2009 14:05:31 -0400

I submitted:

https://sourceforge.net/tracker/?func=detail&aid=2730965&group_id=6663&atid=106663

to get the same behavior when a password is changed on 1970 01 01 with PAM.

Michael, in you patch, is it really needed to raise a warning?