Today needed to change my user password, but was unable to. Even when I tried changing it when logged into root it failed. Even changing the root password failed. Finally I created a new user and tried changing its password and that failed. The error is always the same: passwd: Authentication token manipulation error I checked permissions, tried various USE flags, booting from another OS and chrooting, etc, etc. Nothing seemed to work. Finally I downgraded pam and pambase to the stable versions: sys-libs/pam-1.3.1_p20200128-r1 sys-auth/pambase-20200304 After the downgrade I was able to run passwd successfully. This happened on both of my Gentoo systems. Not sure if it makes a difference but both systems use systemd. Reproducible: Always Steps to Reproduce: 1. Upgrade to sys-libs/pam-1.4.0_p20200809 and sys-auth/pambase-20200817 2. Run `passwd [user]` Actual Results: # passwd marduk passwd: Authentication token manipulation error passwd: password unchanged Expected Results: Prompt for new password. As I said, downgrading to the stable versions of pam/pambase. I'm not sure which package fixes it but apparently you need to downgrade both. I can authenticate users just fine, it's just that I cannot change the password. I know for this user I was able to change the password on 31 July, but that was probably with an older pam/pambase. The work-around is to downgrade, but it's not immediately obvious (to me) so it was a lot of trial and error changing USE flags, checking file permissions, etc. This happens on two systems: one is a laptop running GNOME and the other is a simple headless server. No NIS, LDAP or anything fancy like that. Just simple passwd/shadow files.
# emerge --info pam Portage 3.0.4 (python 3.7.9-final-0, default/linux/amd64/17.1/systemd, gcc-10.2.0, glibc-2.32, 5.8.3-gentoo x86_64) ================================================================= System Settings ================================================================= System uname: Linux-5.8.3-gentoo-x86_64-Intel-R-_Xeon-R-_CPU_E5-2630_0_@_2.30GHz-with-gentoo-2.7 KiB Mem: 32884752 total, 4980928 free KiB Swap: 3145724 total, 3145724 free Timestamp of repository gentoo: Sat, 22 Aug 2020 14:44:07 +0000 Timestamp of repository marduk: Sat, 22 Aug 2020 12:46:02 +0000 sh bash 5.0_p18 ld GNU ld (Gentoo 2.34 p6) 2.34.0 app-shells/bash: 5.0_p18::gentoo dev-lang/perl: 5.30.3-r1::gentoo dev-lang/python: 3.7.9::gentoo dev-util/pkgconfig: 0.29.2::gentoo sys-apps/baselayout: 2.7::gentoo sys-apps/sandbox: 2.20::gentoo sys-devel/binutils: 2.34-r2::gentoo sys-devel/gcc: 10.2.0::gentoo sys-devel/gcc-config: 2.3.1::gentoo sys-devel/make: 4.3::gentoo sys-kernel/linux-headers: 5.8::gentoo (virtual/os-headers) sys-libs/glibc: 2.32::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://blackwidow/portage priority: -1000 sync-rsync-extra-opts: sync-rsync-verify-jobs: 1 sync-rsync-verify-max-age: 24 sync-rsync-verify-metamanifest: False marduk location: /var/db/repos/marduk sync-type: rsync sync-uri: rsync://blackwidow/local-portage masters: gentoo priority: 50 sync-rsync-extra-opts: sync-rsync-verify-metamanifest: False ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="@FREE @BINARY-REDISTRIBUTABLE" CBUILD="x86_64-pc-linux-gnu" CFLAGS=" -O2 -march=native -pipe " CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS=" -O2 -march=native -pipe " DISTDIR="/var/cache/distfiles" EMERGE_DEFAULT_OPTS=" --alphabetical --autounmask=n --buildpkg-exclude=sys-kernel/gentoo-sources --changed-deps=y --color=n --jobs=5 --nospinner --unordered-display --verbose-conflicts --with-bdeps=y --binpkg-changed-deps --binpkg-respect-use --buildpkg --color=y --getbinpkg --rebuilt-binaries=y --with-bdeps=n " ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg cgroup config-protect-if-modified distlocks fixlafiles ipc-sandbox multilib-strict network-sandbox news noinfo notitles parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms skiprocheck strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS=" --jobs=5 --load-average=5.64 --output-sync --print-directory " PKGDIR="/var/cache/binpkgs" PORTAGE_BINHOST="http://blackwidow/packages/blackwidow/" PORTAGE_COMPRESS="" PORTAGE_COMPRESS_FLAGS="" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" USE="acl aes amd64 asm avx ipv6 libglvnd mmx mmxext nptl pam popcnt seccomp split-usr sse sse2 sse3 sse4_1 sse4_2 ssse3 systemd threads unicode urandom xattr" ABI_X86="64" CPU_FLAGS_X86="aes avx mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" CURL_SSL="openssl" ELIBC="glibc" GRUB_PLATFORMS="pc" INPUT_DEVICES="libinput" KERNEL="linux" NGINX_MODULES_HTTP="addition auth_basic autoindex fancyindex gzip headers_more proxy rewrite sub upload uwsgi" PYTHON_SINGLE_TARGET="python3_7" PYTHON_TARGETS="python3_7" QEMU_SOFTMMU_TARGETS="i386 x86_64" QEMU_USER_TARGETS="i386 x86_64" USERLAND="GNU" Unset: CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS ================================================================= Package Settings ================================================================= sys-libs/pam-1.4.0_p20200809::gentoo was built with the following: USE="-audit -berkdb -debug -filecaps -nis pie (-selinux) (split-usr)" ABI_X86="-32 (64) (-x32)" [binary R ] sys-auth/pambase-20200817-1::gentoo USE="-caps -debug (-elogind) -gnome-keyring -minimal -mktemp -nullok -pam_krb5 -pam_ssh -passwdqc -pwquality -securetty (-selinux) -sha512 systemd" 0 KiB I did not downgrade shadow, though I see that it was upgraded yesterday. ls -l /bin/passwd -rws--x--x 1 root root 56256 Aug 21 08:47 /bin/passwd
It'd help quite a bit to have any messages from syslog/journalctl at the time of the failure(s). Can you verify you have run dispatch-conf to update any e.g. pam.d or other config files? Please also see https://bugs.gentoo.org/738256#c3.
I think this bug is invalid, but lets check my guess. 1.) what were your sys-apps/pambase flags before downgrade back to stable versions 2.) what were/are your sys-apps/shadow flags?
Yeah, this could be a config issue, but I have no idea what it is. For my laptop that might make sense because I've got systemd, GNOME, and at one point tried fingerprint authentication. For my server though: it's just a headless box I ssh into. The only "weird" things I can think of about it is it's ~amd64 and it runs systemd. It's peculiar because it seems to be both systems and on both systems I'm able to log in just fine (gdm, ssh, virtual console) but I just can't seem to change passwords. On the system I downgraded that now works: [binary R ] sys-libs/pam-1.3.1_p20200128-r1-1::gentoo USE="-audit -berkdb -cracklib -debug -filecaps -nis pie (-selinux) (split-usr) -static-libs" 0 KiB [binary R ] sys-auth/pambase-20200304-3::gentoo USE="-caps (-consolekit) -cracklib -debug -elogind -minimal -mktemp -nullok -pam_krb5 -pam_ssh -passwdqc -securetty (-selinux) sha512 systemd" 0 KiB Upgrade (now) wants this: binary U ] sys-libs/pam-1.4.0_p20200809-2::gentoo [1.3.1_p20200128-r1::gentoo] USE="-audit -berkdb (-cracklib%) -debug -filecaps -nis pie (-selinux) (split-usr) (-static-libs%)" 0 KiB [binary U ] sys-auth/pambase-20200817-1::gentoo [20200304::gentoo] USE="-caps (-consolekit%) (-cracklib%) -debug -elogind -gnome-keyring% -minimal -mktemp -nullok -pam_krb5 -pam_ssh -passwdqc -pwquality% -securetty (-selinux) sha512 systemd" 0 KiB There seems to be an upgrade of pambase since I reported this bug. I'll try that and get back. As far as the logs... nothing shows up in journand other than when I log in (successfully). Running `passwd` doesn't generate anything in the logs. I did run strace on `passwd` but didn't see anything peculiar. I will paste that after I've sanitized it. Flags for current shadow: [binary R ] sys-apps/shadow-4.8.1-r3-1::gentoo USE="acl -audit -bcrypt -cracklib nls pam (-selinux) -skey (split-usr) -su xattr" 0 KiB
Forgot to mention that etc-update doesn't show anything needing changes.
Created attachment 656388 [details] strace of `passwd` as root Attached the strace of running `passwd` as root. I edited out anything sensitive.
Ok, it looks like everything works with the newer pam/pambase when I enabled the passwdqc USE flag for pambase. Looking at /etc/pam.d/system-auth, it looks like it's required there: password required pam_passwdqc.so min=8,8,8,8,8 retry=3 However with -passwdqc then that it's not there, so that appears fine. So I'm not sure why it's not working w/o the flag.
Note that originally I had passwdqc disabled on both stable and latest versions, so I'm not sure why it makes a difference with the latest.
Using the latest pam/pambase. The only difference is the USE flag and the following in /etc/pam.d: # diff -Naur pamd.broke pamd.working diff -Naur pamd.broke/system-auth pamd.working/system-auth --- pamd.broke/system-auth 2020-08-23 17:04:57.506185304 -0700 +++ pamd.working/system-auth 2020-08-23 17:47:12.042947372 -0700 @@ -7,6 +7,7 @@ account required pam_unix.so account optional pam_permit.so account required pam_faillock.so +password required pam_passwdqc.so min=8,8,8,8,8 retry=3 password required pam_unix.so try_first_pass use_authtok sha512 shadow password optional pam_permit.so -session optional pam_systemd.so
(In reply to Albert W. Hopkins from comment #7) > Ok, it looks like everything works with the newer pam/pambase when I enabled > the passwdqc USE flag for pambase. > > Looking at /etc/pam.d/system-auth, it looks like it's required there: > > password required pam_passwdqc.so min=8,8,8,8,8 retry=3 > > However with -passwdqc then that it's not there, so that appears fine. So > I'm not sure why it's not working w/o the flag. You should not disable it without full understanding. With the USE=pam flag enabled on sys-apps/shadow pam stack needs a plugin to handle passwords (in that case it is either pwquality or passwdqc). In older versions of pambase there was the USE=cracklib which also provided an alternative password plugin (now deprecated). Bear in mind that cracklib in pambase and cracklib in shadow are different things. Shadow provides its own cracklib implementation or relies on pam. So you can (either way): 1.) enable cracklib on shadow and go with its own implementation 2.) enable pam on shadow, but be careful in regards with pambase's flags 3.) disable cracklib and pam flags in shadow (no passwords check will happen then).
(In reply to Mikle Kolyada from comment #10) > You should not disable it without full understanding. With the USE=pam flag > enabled on sys-apps/shadow pam stack needs a plugin to handle passwords (in > that case it is either pwquality or passwdqc). In older versions of pambase > there was the USE=cracklib which also provided an alternative password > plugin (now deprecated). Bear in mind that cracklib in pambase and cracklib > in shadow are different things. Shadow provides its own cracklib > implementation or relies on pam. So you can (either way): > > 1.) enable cracklib on shadow and go with its own implementation > 2.) enable pam on shadow, but be careful in regards with pambase's flags > 3.) disable cracklib and pam flags in shadow (no passwords check will happen > then). Thanks for the details. Will disable pam in shadow.
(In reply to Mikle Kolyada from comment #10) > You should not disable it without full understanding. With the USE=pam flag > enabled on sys-apps/shadow pam stack needs a plugin to handle passwords (in > that case it is either pwquality or passwdqc). In older versions of pambase > there was the USE=cracklib which also provided an alternative password > plugin (now deprecated). Bear in mind that cracklib in pambase and cracklib > in shadow are different things. Shadow provides its own cracklib > implementation or relies on pam. So you can (either way): > > 1.) enable cracklib on shadow and go with its own implementation > 2.) enable pam on shadow, but be careful in regards with pambase's flags > 3.) disable cracklib and pam flags in shadow (no passwords check will happen > then). Sorry, but in that case why doesn't shadow[pam] depend on pambase[passwdqc||pwquality]? (Notation mine, I don't fully comprehend syntax for USE depends in ebuilds.) The problem is that pam is often enabled by default globally and passwdqc and pwquality are often disabled in user configs. And it's a trap with error messages that don't tell you exactly what's happening (even with help from Google) unless you dig deep enough. Also IMHO shadow should in this case have custom description for pam use flag so users have a chance to figure out what this flag really does there.
