This is a quite nasty one. passwd does not work anymore on *no* Gentoo box. Tested on a dozen of different boxes, admittedly all with recent packages. To reproduce, as root: # passwd passwd: Authentication token manipulation error This must have happend within the last couple of days. Most probably by the pambase update. I have found a single outdated system without that issue. It has the following packet versions installed: # equery l -po pambase [I--] [??] sys-auth/pambase-20190402:0 [-P-] [ ] sys-auth/pambase-20200304:0 [-P-] [ ~] sys-auth/pambase-20200817:0 # equery l -po shadow [I--] [??] sys-apps/shadow-4.8-r4:0 [-P-] [ ] sys-apps/shadow-4.8-r5:0 [-P-] [ ~] sys-apps/shadow-4.8.1-r3:0 # equery l -po pam [IP-] [ ] sys-libs/pam-1.3.1_p20200128-r1:0 [-P-] [ ~] sys-libs/pam-1.4.0_p20200829:0 Unfortunatelly, the old packages have already been removed from portage. My current workaround: USE="-pam" emerge shadow Please advise.
Please show us the syslog output.
(In reply to Sam James from comment #1) > Please show us the syslog output. + show the flags you built pambase with.
Here some more information: (1) passwd as root # passwd passwd: Authentication token manipulation error passwd: password unchanged Nothing in systemd's journal (syslog). (2) passwd as a user $ passwd Changing password for user1. Current password: # <- no 2nd pw entry requested passwd: Authentication failure passwd: password unchanged syslog: passwd[10099]: pam_unix(passwd:chauthtok): authentication failure; logname= uid=1100 euid=0 tty= ruser= rhost= user=user1 (3) USE flags # equery u pambase + + caps - - debug - - elogind - - gnome-keyring - - minimal - - mktemp - - nullok - - pam_krb5 - - pam_ssh - - passwdqc - - pwhistory - - pwquality - - securetty - - sha512 + + systemd # equery u pam - - audit - - berkdb - - debug + + filecaps - - nis + + pie # equery u shadow - - acl - - audit - - bcrypt - - cracklib - - nls + + pam - - skey + + su - - xattr (4) pam configs cd /etc/pam.d/ cat passwd auth sufficient pam_rootok.so auth include system-auth account include system-auth password include system-auth cat system-auth auth required pam_env.so auth required pam_unix.so try_first_pass likeauth auth optional pam_permit.so auth required pam_faillock.so preauth auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail account required pam_unix.so account optional pam_permit.so account required pam_faillock.so password required pam_unix.so try_first_pass use_authtok md5 shadow password optional pam_permit.so -session optional pam_libcap.so session required pam_limits.so session required pam_env.so session required pam_unix.so session optional pam_permit.so Thanks!
I've found a Gentoo system with the slightly older pambase-20200917 which is also hit by the issue.
Not a bug, you have broken the stack by disabling passwdqc, you should have full understanding of what is going on before disable defaults.
Thanks for the pointer and your time to help. I will investigate why disabling a password quality check prevents from setting the password at all. This just sounds like a feature to me, not something critical.
(In reply to m1027 from comment #6) > Thanks for the pointer and your time to help. > > I will investigate why disabling a password quality check prevents from > setting the password at all. This just sounds like a feature to me, not > something critical. then you need to disable pam on shadow indeed.
Okay, so if pambase -passwdqc somewhat breaks passwd, and requires to have shadow -pam support then, I imagine there is a way to prevent that by either an ebuild hint (or even a hard assert). Not being an ebuild junkie yet, this is kind of a pseudo code: <ebuild pseudo code for pambase> if !passwdqc && shadow +pam then big warning/die </ebuild preudo code for pambase> <ebuild pseudo code for shadow> if +pam & pambase -passwdqc then big warning/die </ebuild preudo code for shadow> Just my 2p in case anybody is willing to care.
Just hit this bug myself and also did some investigation. With sys-auth/pambase-20201013 with USE=-passwdqc /etc/pam.d/system-auth contains $ grep password /etc/pam.d/system-auth password required pam_unix.so try_first_pass use_authtok nullok sha512 shadow password optional pam_permit.so There is no authtok to use so use_authtok causes failure. The old code that worked from sys-auth/pambase-20200304 removed use_authtok from the pam_unix.so line unless cracklib or passwordqc or krb5 were being used (see https://github.com/gentoo/pambase/blob/7eaf47da1d6cd18a8253c25213c34b16ae08e87f/basic-conf). There has been a big rewrite using a different way to generate the files and either this logic wasn't maintained for some reason or this is a valid bug.
Fixed in sys-auth/pambase-20201028.1 (see https://github.com/gentoo/pambase/commit/74b99b4462138ed6b496725b2499fb5d17ad9371)
