Recently passwd behaviour has changed and is refusing to set new passwords on new stage3 installs, as root, with the default passwd configuration of PASS_ALWAYS_WARN=yes Reproducible: Always Steps to Reproduce: 1. wget https://raw.githubusercontent.com/nathanshearer/gentooinstall/master/gentooinstall 2. chmod a+x gentooinstall 3. ./gentooinstall -t "Canada/Mountain" Actual Results: Installing Gentoo Linux... Destination: "/mnt/gentoo" Architecture: "x86_64" Downloading the stage 3 tarball... done. Verifying the cryptographic signature of the stage3 hashes... Success. Verifying the hash of the stage3 tarball... Success. Extracting "/mnt/gentoo/stage3-amd64-20201025T214503Z.tar.xz" to "/mnt/gentoo"... done. Not installing qemu for dynamic binary translation because the host and guest are the same architecture. Adding 8.8.8.8 and 8.8.4.4 to /etc/resolv.conf Installing portage... done. Setting the timezone to "Canada/Mountain"... done. Setting the locale to "en_US ISO-8859-1" and "en_US.UTF-8 UTF-8"... done. Updating world packages... done. Weak password: based on a dictionary word and not a passphrase. chpasswd: (user root) pam_chauthtok() failed, error: Authentication token manipulation error chpasswd: (line 1, user root) password not changed error: the password phase encountered an error Expected Results: When called by root, the passwd utility should follow the original default behaviour of PASS_ALWAYS_WARN=yes and actually set the new password. I know the default password is "weak". This is intentional for the stage4 image. But the expected behaviour of passwd (as root) is to warn and continue, not fail and return a "token manipulation error". More advanced users can generate images and deploy them with random passwords when desired, rather than changing the password after imaging.
You may need to modify passwdqc config.
As announced, the latest pam version has changed from pam_cracklib to pam_passwdqc to verify passwords. The default of passwdqc is to apply to everyone and not just non-root users. Simply changing /etc/security/passwdqc.conf enforce value will be similar to cracklib's treatment of root
The news item stated that nothing needed to be done if I did not make any manual changes. However, the new behaviour is different for root, which was to originally warnt and continue rather than fail by default: You only need to take action if: * you made manual changes to the PAM stack, or * you use FEATURES="-config-protect-if-modified" option If this applies to you, please make sure to either run the etc-update or dispatch-conf command in order to sync your configuration. Failure to do this may result in your system becoming inaccessible. Looking at the passwdqc.conf manpage, I can see that setting enforce=users would restore the original behaviour of warn and continue. And this would prevent a lot of existing scripts from breaking. I can also see that in the stage3 tarball that /etc/security/passwdqc.conf is provided and has a non-default entry for min=8,8,8,8,8 which differs from the passwdqc default of min=min=disabled,24,11,8,7 I think the original behaviour of enforce=users should be in the gentoo-provided passwdqc.conf file.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2820aee152f31d8627ab8c1dc42d38240ad108b5 commit 2820aee152f31d8627ab8c1dc42d38240ad108b5 Author: Lars Wendler <polynomial-c@gentoo.org> AuthorDate: 2020-10-29 14:02:53 +0000 Commit: Lars Wendler <polynomial-c@gentoo.org> CommitDate: 2020-10-29 14:03:01 +0000 sys-devel/gettext: Removed old Closes: https://bugs.gentoo.org/751631 Package-Manager: Portage-3.0.8, Repoman-3.0.2 Signed-off-by: Lars Wendler <polynomial-c@gentoo.org> sys-devel/gettext/Manifest | 2 - .../files/gettext-0.20-avoid_eautomake.patch | 22 --- sys-devel/gettext/gettext-0.20.1.ebuild | 152 --------------------- sys-devel/gettext/gettext-0.20.2.ebuild | 152 --------------------- 4 files changed, 328 deletions(-)
Sorry, wrong bug referenced...
No, if you set a short password you take responsibility for that. So please do.
So no discussion here at all? Just close the bug as "invalid"? With the new password policy the current default actually accepts "asdfasdfasdfasdf" as a password, which is clearly not a secure password and doesn't really follow the spirit of forcing users, including root, to use a password that is safer. A new policy which is different from existing behaviour, which is breaking existing scripts. What policy should be used? Why is the current one considered acceptable? Who made that decision and chose this policy? I'm just making a few honest points here... 8 Character passwords are not secure anyways, even if they are truely random. I don't intend to argue for weak passwords. In fact, the previous behaviour was to warn and continue, and that was only applied to root. Regular non-root users still were subject to more strict passwords, while root was at least granted more freedom with a warning. I just opened this bug because my existing script started failing when the behaviour changed. I read that news item, and it explicitly stated that no changes were needed on my part. I expect there are a lot of other scripts that will also be affected by this. At the very least maybe issue another news item indicating that the passwd behaviour is now different and that changes may be required.
As others have already explained, you can change the settings if you disagree with the defaults (that is why lots of modules are now managed via the /etc/security files). We are not responsible for custom installation scripts.
