if system date is set to 01-01-1970 users are enforced to update their password
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
shadow (Ubuntu) |
Fix Released
|
High
|
Michael Casadevall |
Bug Description
If the system date is set to jan 1st 1970 (as it happens on many ARM devices that are freshly installed and not attached to a network) the third field in /etc/shadow (* days since Jan 1, 1970 that password was last changed) is set up zero.
This breaks autologin on the live images in a way that all ttys die on bootup and the system becomes unusable on the console (under X you get a message that your password is expired and you need to update immediately)
The useradd tool should special case this specific date to set a bigger value for the second field in shadow or the special casing for a value of 0 in the above mentioned field should be removed. Accordingly the manpage of shadow should mention that a value of zero actually enforces a password update (it only talks about "last changed since 1970" currently but gives no indication that this breaks autologin through the above behavior)
Related branches
Changed in shadow (Ubuntu): | |
importance: | Undecided → High |
milestone: | none → ubuntu-9.04 |
Changed in shadow (Ubuntu): | |
assignee: | nobody → mcasadevall |
status: | New → Confirmed |
Changed in shadow (Ubuntu): | |
status: | Confirmed → In Progress |
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/FMoE6Aj3Ag cpNgbPQq. Ww2CowvAWeujm7q t9AdqskPtrLj3we 4hYw8JsGSA6KN3t 4dhlTL4uJmxi9Ru J/:0:0: 99999:7: ::
Breaking this down, this account has the following settings
Username: test Nar6/FMoE6Aj3Ag cpNgbPQq. Ww2CowvAWeujm7q t9AdqskPtrLj3we 4hYw8JsGSA6KN3t 4dhlTL4uJmxi9Ru J/
Encrypted Password (which is test): $6$34MquWg3$
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: 34MquWg3$ Nar6/FMoE6Aj3Ag cpNgbPQq. Ww2CowvAWeujm7q t9AdqskPtrLj3we 4hYw8JsGSA6KN3t 4dhlTL4uJmxi9Ru J/:::99999: 7:::
test:$6$
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.