passwd: Authentication token manipulation error when use_authtok is used on pam_unix.
kjetilk opened this issue · 2 comments
I'm struggling to change a password as root on a Debian Bookworm box. I don't have a lot to go on, but I was encouraged on IRC to post what I have. This is the symptom:
root@robin:~# passwd
passwd: Authentication token manipulation error
passwd: password unchanged
My audit.log has the following line when the above happens:
type=USER_CHAUTHTOK msg=audit(1704752899.121:107538): pid=3320082 uid=0 auid=0 ses=4 subj=unconfined msg='op=PAM:chauthtok grantors=? acct="root" exe="/usr/bin/passwd" hostname=robin addr=? terminal=pts/1 res=failed'UID="root" AUID="root"
Here are some things that may help debug this:
- an strace
- my /etc/login.defs
- my /etc/nsswitch.conf
- my /etc/pam.d/passwd
- my /etc/pam.d/other
- my /etc/pam.d/common-password.txt
In addition, I have had etckeeper running for several years, and the logs show that there aren't many significant changes, as I think will also be visible in the config files above. This is a short summary of the commits:
root@robin:/etc (master)# git log --pretty=reference login.defs nsswitch.conf pam.d/
2c3c035 (daily autocommit, 2024-01-06)
8fb4664 (committing changes in /etc made by "apt full-upgrade", 2023-11-02)
a8d94dc (committing changes in /etc made by "apt install powertop", 2022-08-08)
8525979 (committing changes in /etc made by "apt-get install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils", 2021-09-06)
e8828d4 (committing changes in /etc made by "apt full-upgrade", 2021-09-04)
9956f7c (committing changes in /etc made by "apt-get dist-upgrade", 2021-06-27)
72c342a (committing changes in /etc made by "apt-get autoremove", 2019-09-24)
0627a50 (committing changes in /etc made by "apt-get install debhelper cmake doxygen pkg-config sqlite3 libproj-dev libgdal-dev qtbase5-dev qtbase5-private-dev qtbase5-dev-tools qttools5-dev qttools5-dev-tools libqt5sql5-sqlite libpolyclipping-dev zlib1g-dev libcups2-dev", 2019-08-18)
dc03e2d (daily autocommit, 2019-08-04)
I suspect that this broke after the bookworm upgrade on 2023-11-02, but I can't be sure about that as I didn't discovered before last week. The commit on 2024-01-06 happened because my first response was to disable pam_winbind
as wasn't using it anyway. It didn't fix the problem.
Thanks for posting these.
If you look at your /etc/pam.d/common-password, it has some extra entries over and above a clean bookwurm install. Clean install has:
# here are the per-package modules (the "Primary" block)
password [success=1 default=ignore] pam_unix.so obscure yescrypt
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
Yours has:
# here are the per-package modules (the "Primary" block)
password [success=2 default=ignore] pam_systemd_home.so
password [success=1 default=ignore] pam_unix.so obscure use_authtok try_first_pass yescrypt
# here's the fallback if no module succeeds
password requisite pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password required pam_permit.so
# and here are more per-package modules (the "Additional" block)
password optional pam_gnome_keyring.so
Good catch, and that did indeed fix it. This box certainly does not need the Gnome keyring, but it was in there when I first committed in 2019. It seems that pam_systemd_home.so
is added by default pam-auth-update
, but reading docs, I don't need that either. Both of those seem harmless though.
Drilling down into it, I find that the problem occurs when use_authtok
is used. I don't know if that's a bug or a failure to RTFM on my part, but I'll change the title in case it is something that should be fixed.