passwd: Authentication token manipulation error when use_authtok is used on pam_unix.

[kjetilk]

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.

[hallyn]

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 

[kjetilk]

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.