Description of problem: After the recent system update, I've lost the root access to the local PC. sudo says this: --- sudo: Account or password is expired, reset your password and try again --- But this user is password-less! How it could expire? su says this: --- Password: <typing root password> You are required to change your password immediately (administrator enforced). --- But I am an administrator, its my home PC! Same thing happens when I try to log in as root from virtual console. Version-Release number of selected component (if applicable): shadow-utils-4.8.1-10.fc35.x86_64 How reproducible: easily Steps to Reproduce: 1. sudo -s 2. su Actual results: Some blabbering that the administrator (which is me) forces me to change the password. Or that the password of the password-less user have expired. Expected results: Should work as it did for 25 years for me. Additional info: Seems like updating the system can sometimes be much worse than being hacked... :(
Created attachment 1787676 [details] screen-shot of chage -l Managed to hack into the system with the boot tricks. Still can't hack out root under GUI, so had to photo the screen-shot. It clearly shows that all restrictions and agings are disabled on my passwords. And yet, after an update, I suddenly can't log in because everything got "expired"...
This appears to be the PAM bug. After adding no_pass_expiry to pam_unix.so in /etc/pam.d/system-auth some login scenarios started to work, namely "login -f" started to work. But still not the normal login. But after I changed account required pam_unix.so to account required pam_permit.so things started to work as before. So obviously pam_unix.so is broken.
pam-1.5.1-5.fc35.x86_64
This is a bug with libxcrypt 2.2.41. There is already a build of v4.4.22 available, which should fix this issue.
*** This bug has been marked as a duplicate of bug 1965149 ***
No, its not fixed. Upgraded to libxcrypt-4.4.22-1.fc35.x86_64 sudo now works - big relief. user login now works - also good. su still doesn't work: Password: You are required to change your password immediately (administrator enforced). Current password: root login still doesn't work. In a mean time, let me note that this is the worst bug I've ever seen. Not too many people will come for an update: they will just lose their system.
Is this change in libxcrypt really thought through? Apparently it is much more invasive than expected. And should have been done in Rawhide only!
(In reply to Stas Sergeev from comment #6) > No, its not fixed. > Upgraded to libxcrypt-4.4.22-1.fc35.x86_64 > > sudo now works - big relief. > user login now works - also good. > > su still doesn't work: > > Password: > You are required to change your password immediately (administrator > enforced). > Current password: > > root login still doesn't work. Have you tried to change the root password, as the system requires you at the login prompt? I've tried myself by manually setting the hash for the root password to something really ancient like md5crypt, which was commonly used until 2009. I can login with that password, and I am immediately asked to change it, which works flawlessly. BTW, you can also change your root password using sudo: `sudo passwd root` > > In a mean time, let me note that > this is the worst bug I've ever seen. > Not too many people will come for > an update: they will just lose their > system. As I already stated, one can login, change their pw and things are fine. Once the pw has been changed, one can change it back to the well-known previous one, if they prefer to. *** (In reply to Tomáš Mráz from comment #7) > Is this change in libxcrypt really thought through? Apparently it is much > more invasive than expected. And should have been done in Rawhide only! Well, the bug reporter didn't change their root pw since 2005 (see screenshot). Also the change in libxcrypt doesn't block anyone from logging in; they are simply requested to change their pw, if they still use a hash computed using descrypt and/or md5crypt. Users, who changed their pw within the last 10 years, are not affected. Also, libxcrypt v4.4.22 is still in (and will remain there for a longer period of time) updates-testing for F34 and earlier. Anyways, the logic (call to crypt_checksalt), that triggers the request to change the pw, is in PAM since a long time, it hasn't just been activated in previous versions of libxcrypt. The fact few people are now requested to change their password is basically a security consideration, as they are still using a dangerously flawed hash in the shadow file.
Just for the records: Logging into the root account with an ancient pw hash from terminal and `su` works. The request to change the password comes up, and the password can be changed successfully.
> Have you tried to change the root password, as the system requires you at the login prompt? I tried to specify the same password, yes. It doesn't let me do so. I haven't tried anything else because the expiration of that password is disabled, so the message is ibviously wrong. > The fact few people are now requested to change their password is basically a security consideration, > as they are still using a dangerously flawed hash in the shadow file. Thanks for an explanation, but can it be handled in a better way? Rather than preventing a login and telling people that the never expiring password have expired, how about to write a warning: "Your password uses hash XXX that is known to be vulnerable since year YYY. You should change your password to update its hash to ZZZ because it is known to be strong in year 2021.", and in case of the disabled expiration, allow the user to just type the previous password? Please note that when you see the totally absurd message, like that "you are ordered to change your password immediately, type your password now or administrator will kill you!", the first thing you think is that you've being hacked. This means, you will sure as hell NOT type your password (to a key-logger), but rather try to hack into the system by some other means. So if you want people to follow your request, please get rid of the absurd messages first.
FEDORA-2021-e6916d6758 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-e6916d6758
FEDORA-2021-fed63bd217 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-fed63bd217
FEDORA-2021-fed63bd217 has been pushed to the Fedora 33 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-fed63bd217` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-fed63bd217 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-e6916d6758 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-e6916d6758` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-e6916d6758 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
I confirm that libxcrypt-4.4.22-2.fc35.x86_64 seems to have fixed it for me. It doesn't print a warning about an insecure hash though, which might still be good to have. Thanks for fixing this problem.
FEDORA-2021-e6916d6758 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2021-fed63bd217 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.