| Summary: | sys-auth/pambase-20201013, sys-apps/shadow-4.8-r5: passwd: Authentication token manipulation error | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | m1027 <m1027> |
| Component: | Current packages | Assignee: | Mikle Kolyada (RETIRED) <zlogene> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
m1027
2020-10-15 12:41:11 UTC
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) |
