Errors from cron re "Auth. token is no longer valid"...
Every day cron sends me email with this in it:
/etc/cron.daily/dwww:
You are required to change your password immediately (root enforced)
su: Authentication token is no longer valid; new one required.
(Ignored)
/etc/cron.daily/mailman:
You are required to change your password immediately (root enforced)
su: Authentication token is no longer valid; new one required.
(Ignored)
You are required to change your password immediately (root enforced)
su: Authentication token is no longer valid; new one required.
(Ignored)
... and I think that this should not happen; I should not have to set
the password expiry dates and intervals for these accounts - they
should have been set for me when the stuff gets installed, I think.
I looked in the `dwww' cron script and found that it is using `su' to
become `www-data'.
# passwd -S www-data
www-data L 01/01/1970 0 65535 10 365
The `www-data' account is `L'ocked, the password was last changed at
the Unix epoch, the minimum password age is 0 days, the maximum age
is 65535 days, the warning period is 10 days, and the inactivity
period is 365 days. Hmmm. So why does it print the warning message?
Surely it has not been more than 65535 days since the Unix epoch ???
According to my calculations, I should not have to change the
`www-data' password until Fri Jun 6, 2149. Unless "65535" is really
"-1" becuase it's being kept in a signed integer or what?
UTSL/RTFS pending... Hmmm... libpam, I guess. We need to find out if
it's the date in the last modified field that triggers this warning,
or if it's that the password is blank. I think something is wrong
with the way this works now. The warnings seem superfluous to me.
Unlocking the password, and then viewing it's status again reveals:
# passwd -S www-data
www-data NP 01/01/1970 0 65535 10 365
The `NP' indicates that there is no password for this account.
Locking then unlocking it does not update the last modified date, but
I found that by setting a password for the account (and locking it of
course), a `su www-data -c date' runs fine, with no warning, and that
`passwd -S www-data' shows todays date in the last changed field.
Should toggling the lock on an account with `passwd' update the
last-modified field? It does not now. That's likely intended.
What's the reasoning behind this behaviour? (The password hasn't
changed.)
What can be done about this, so that folks won't have to set the
passwords for those system accounts to get rid of these warnings? Or
should we just have them set passwords for them? Perhaps all that's
required of us is to mention this during the installation process?
Reply to: