This bug is a follow-on to bug #802267 . Turns out the immediate trigger there was an upstream bug with a fix committed that will be in the next pam release. Given the situation with the gentoo libxcrypt migration I'd suggest cherry-picking upstream's patch and doing a revision-bump. The upstream commit: https://github.com/linux-pam/linux-pam/commit/980d90c9232fe5325d1a4deddd42c597cf9e1a54 pam_unix: do not use crypt_checksalt when checking for password expir… …ation According to Zack Weinberg, the intended meaning of CRYPT_SALT_METHOD_LEGACY is "passwd(1) should not use this hashing method", it is not supposed to mean "force a password change on next login for any user with an existing stored hash using this method". This reverts commit 4da9feb. * modules/pam_unix/passverify.c (check_shadow_expiry) [CRYPT_CHECKSALT_AVAILABLE]: Remove. Closes: #367 ---- The original issue was filed against libxcrypt, which resulted in an issue against pam, which resulted in the revert above. Here's the two issue links: https://github.com/besser82/libxcrypt/issues/130 https://github.com/linux-pam/linux-pam/issues/367 [The below just summarizes the above issues and commit.] Like me in the followed-up-from bug above, the report was a forced-password-change that failed due to a read-only root. (Tho he was on arch and the old hash was sha-256, while I'm of course on gentoo and my old hash was md5.) Quoting from a developer comment on the libxcrypt issue... Note that libcrypt does not set policy. We export one function, crypt_checksalt, that reports compiled-in information about hashes that are supported. Before 4.4.22, it only told callers whether any given hash had been enabled at compile time (CRYPT_SALT_OK) or disabled at compile time (CRYPT_SALT_INVALID). The change in 4.4.22 was to add a third possible return value, CRYPT_SALT_LEGACY, which is used for hashing methods that we don't think are strong enough for new hashes. In other words, passwd(1) should not use those methods. Existing hashes using those methods will still be accepted by our crypt and crypt_r* functions. [pam_unix.so] calls crypt_checksalt and refuses to authenticate a user whose hash is reported as LEGACY. I would consider this to be a bug in that implementation of login. The only thing I ever expected login to do with a LEGACY hash is re-hash the user's existing password with a non-LEGACY method upon successful login. That eventually lead to the PAM issue being opened and the libxcrypt issue being closed. While the rehashing-existing-password bit is still being discussed and may or may not be implemented, what PAM has done for now is revert their use of crypt_checksalt() for password-expiration check entirely. That's the proposed cherry-pick-for-revision-bump above.
Hmm. so the investigation direction was right :/ Ok, this is probably better to take the top of the master branch, not just that commit, as ldv has improved libxcrypt autodetection kerfuffle. I will overview the commits.
New pam snap is in the tree.
(In reply to Mikle Kolyada from comment #2) > New pam snap is in the tree. Just for clarity, snap==snapshot (not the binary all-in-one package type).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/data/gentoo-news.git/commit/?id=d6020a98d364bbc0c0c8f8d5f5efde5bcb1b383e commit d6020a98d364bbc0c0c8f8d5f5efde5bcb1b383e Author: Sam James <sam@gentoo.org> AuthorDate: 2021-07-20 17:42:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-07-22 23:41:09 +0000 2021-06-30-libxcrypt-migration: mention PAM/md5crypt issues Bug: https://bugs.gentoo.org/802267 Bug: https://bugs.gentoo.org/802807 Signed-off-by: Sam James <sam@gentoo.org> .../2021-06-30-libxcrypt-migration.en.txt | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-)
This cherry-pick is contained within 1.5.1_p20210622 [0]. [0] https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=86e19dd5b6ba74010ca22c7a5528e4352494a10e