Using chpass, add an account expiration of a large date. e.g. January 1, 2119 and save. Using chpass again, attempt to fix the date to something more reasonable. e.g. January 1, 2019. When editing a date other than the one originally entered is displayed. For the above example it shows November 24, 1982. Changing the date to January 1, 2019 and saving fails. Error messages displayed:
chpass: entry inconsistent
chpass: pw_copy: Invalid argument
Workaround: zero out the expiration field for the given user using vipw. chpass now works again.
pwd_mkdb.c and getpwent.c store the password change and expire fields as 32-bit ints so cannot be set beyond Jan 19 2038.
Thank you for the report. In the near future I'll add a band-aid to disallow y2038+ dates, before we can implement a full fix.
Proposed patch to disallow y2038 dates in chpass: https://github.com/emaste/freebsd/commit/d69eea06fcc51bf92bccebea3cb25ac84974d664
(y2048 in commit message is a typo)
Ah, it's actually a y2106 problem: on all archs but i386 we have 64-bit time_t but are storing 32-bit unsigned ints in the pwd db. signed 32 bit int goes to 2038, unsigned 32 bit to 2106.
i386 has 32-bit time_t and chpass will already reject post-y2038 dates.
A commit references this bug:
Date: Thu Apr 19 12:50:49 UTC 2018
New revision: 332769
chpass: reject change/expiry dates beyond y2106
The pwd.db and spwd.db files store the change and expire dates as
unsigned 32-bit ints, which overflow in 2106. Reject larger values for
now, until the introduction of a v5 password database.
i386 has 32-bit time_t and so dates beyond y2038 are already rejected by
Reviewed by: lidl
MFC after: 1 week
Sponsored by: The FreeBSD Foundation