why at all? why only on one machine? why suddenly 10 years later? 99999 / 365 = 273 years Jun 2 00:45:01 fileserver crond[121859]: pam_unix(crond:account): expired password for user wwwcron (root enforced) Jun 2 01:00:01 fileserver crond[121864]: pam_unix(crond:account): expired password for user wwwcron (root enforced) Jun 2 01:45:01 fileserver crond[233446]: pam_unix(crond:account): expired password for user wwwcron (root enforced) [root@fileserver:~]$ cat /etc/passwd | grep cron wwwcron:x:4500:48:User fuer www-cronjobs:/mnt/storage/users/wwwcron:/usr/bin/bash [root@fileserver:~]$ chage -l wwwcron Last password change : Feb 01, 2011 Password expires : never Password inactive : never Account expires : never Minimum number of days between password change : 0 Maximum number of days between password change : 99999 Number of days of warning before password expires : 7
Reassigning tentatively to libxcrypt as there was a recent regression seen in bug 1965345
interesting that it only seems to affect crond, "su - wwwcron" from a root ssh shell works just fine
@h.reindl > wwwcron:x:4500:48:User fuer www-cronjobs:/mnt/storage/users/wwwcron:/usr/bin/bash The 'x' is the actual value for the password hash or is it something different? If so, then please give me at least the first five characters, please. Which version of libxcrypt are you using on the F33 machine?
>> wwwcron:x:4500:48:User fuer www-cronjobs:/mnt/storage/users/wwwcron:/usr/bin/bash > The 'x' is the actual value for the password hash or is it something different? this is the *complete* unaltered line > Which version of libxcrypt are you using on the F33 machine? [root@fileserver:~]$ rpm -q libxcrypt libxcrypt-4.4.22-1.fc33.x86_64
Okay, thanks for the info. How does crond use the wwwcron user? How does it try log into it?
@h.reindl Are there any password hashes in /etc/shadow, that start with '$1$', '$5$', or [0-9a-zA-Z./]{2}?
> How does crond use the wwwcron user? How does it try log into it? frankly god knows given that there are only 48 events per day > Are there any password hashes in /etc/shadow, that start with '$1$', '$5$', or [0-9a-zA-Z./]{2}? [root@fileserver:~]$ cat /etc/shadow | grep wwwcron wwwcron:$1$YsbrPS1F$w2N72/y7LQl6XVntSzysc.:15006:0:99999:7::: (yes, that is obfuscated by replacing radmon chars by different ones and the same for numbers)
There we have the cause. The user has been setup at some point before 2009, and never got it's password changed. Does the user really need to login directly? * If yes: Give it a new password, e.g. with mkpass and copy the output into shadow. * If no: replace the password hash in shadow with an asterisk '*'.
hell most of my users are cerated before 2009 and never changed their password and "wwwcron" on the 19 other vms cloned from the same golden-master from 2008 surely has the same god knows why there are only 48 logwatch entries */45 * * * * wwwcron php /scripts/rh_watchdog.php for the sake of god you can't come up with such a breakage in the middle of a stable Ferdora release! this needs to be at https://fedoraproject.org/wiki/Releases/35/ChangeSet with a hint "you need to reset passwors before 2008" so that someone has a chance schedule that for all of it's users and the only reason why this wasn't a total breaking change was that after "heartbleed" i enforced password changes for all real logins
BTW: "Give it a new password, e.g. with mkpass and copy the output into shadow" is stupid given that "passwd wwwcron" exists
I have to say that this "forcibly expire passwords on accounts with old hash" misfeature was not well thought. And I very much agree with Harald here that this should have been an official Fedora 35 System Wide Change if anything. Please revert this on released Fedoras!
For example: Instead of doing this change in this ruthless way there could be a cron/systemd job that would sweep through the hashes and reported in the syslog or through a mail to the sysadmin that this and that user in the /etc/passwd /etc/shadow has an old hash.
Linux PAM upstream decided to revert the trigger of expiration check by the crypt_checksalt() return value. Please see https://github.com/linux-pam/linux-pam/pull/368. Iker, please consider backporting that change to pam in Fedora. This is really breaking change in libxcrypt unless this revert is done.
(In reply to Tomáš Mráz from comment #13) > Linux PAM upstream decided to revert the trigger of expiration check by the > crypt_checksalt() return value. Please see > https://github.com/linux-pam/linux-pam/pull/368. > > Iker, please consider backporting that change to pam in Fedora. This is > really breaking change in libxcrypt unless this revert is done. @t8m: I've taken care of it as a co-maintainer of pam. Update will follow in a short time.
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've taken care of it as a co-maintainer of pam. Update will follow in a > short time. Thanks for taking care of it!
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.