"Current Password:" shows inappropriately when using passwd to change normal user

[nora-pxh]

"Current Password:" shows inappropriately when using passwd command to change the password of the normal user.

Whether the input password on the right of “Current Password:” is correct or not , it will fail.

[root@localhost ~]# su test
[test@localhost root]$ passwd
Changing password for user test.
Current password:
Current Password:
passwd: Authentication token manipulation error
[test@localhost root]$

By the way, the first message "Current password:" is from the pam package,
the seccond message "Current Password:" is from the sssd package.

[sumit-bose]

Hi,

can you add your PAM configuration for the passwd command? It is typically /etc/pam.d/passwd, please note that this file might include other files with include or substack.

bye,
Sumit

[nora-pxh]

Thank you for your attention.
This is the PAM configuration which is the default setting.
[root@localhost ~]# cat /etc/pam.d/passwd
#%PAM-1.0
# This tool only uses the password stack.
password substack system-auth
-password optional pam_gnome_keyring.so use_authtok
password substack postlogin
[root@localhost ~]#

[sumit-bose]

Hi,

thanks, yes, this really looks like the default, can you send /etc/pam.d/system-auth as well?

bye,
Sumit

[nora-pxh]

Hi,
The contents of /etc/pam.d/system-auth are also the default.
[root@localhost ~]# cat /etc/pam.d/system-auth
# Generated by authselect on Sun Oct 11 03:15:45 2020
# Do not modify this file manually.

auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth sufficient pam_fprintd.so
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_usertype.so issystem
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

password requisite pam_pwquality.so try_first_pass local_users_only
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
[root@localhost ~]#

[sumit-bose]

Hi,

this looks ok as well. Can you run passwd with strace like

strace -o /tmp/passwd.out -s 1024 -f passwd

and attach /tmp/passwd.out to this ticket? Please note that /tmp/passwd.out will contain the passwords you are entering at the prompt so please make sure you are using dummy passwords for the test.

bye,
Sumit

[nora-pxh]

Hi, please confirm the following result.
And if you want to confirm other things, please install fedora32 or fedora33,
The same phenomenon exists. Thank you.
[test@localhost root]$ strace -o /home/test/passwd.out -s 1024 -f passwd
Changing password for user test.
Current password:
Current Password:
passwd: Authentication token manipulation error
[test@localhost root]$

passwd.zip

[sumit-bose]

Hi,

thanks for the strace output. Can you check if /usr/bin/passwd and /usr/sbin/unix_chkpwd have the suid bit set?

# ls -al /usr/bin/passwd
-rwsr-xr-x. 1 root root 32624 Jul 29 07:04 /usr/bin/passwd
    ^

I can only reproduce the behavior you are seeing if it is missing for both binaries. You can also check with

# rpm -V passwd
.M.......    /usr/bin/passwd

where M indicates a change in the file mode. rpm -V pam might show other differences as well, but here only changes for /usr/sbin/unix_chkpwd are important.

bye,
Sumit

[nora-pxh]

Hi, please confirm the result. Thanks.
[root@localhost ~]# ls -al /usr/bin/passwd
-rwsr-xr-x. 1 root root 32624 Jul 29 15:04 /usr/bin/passwd
[root@localhost ~]# ls -al /usr/sbin/unix_chkpwd
-rwsr-xr-x. 1 root root 24464 Oct 12 00:30 /usr/sbin/unix_chkpwd
[root@localhost ~]# rpm -V passwd
.......T. c /etc/pam.d/passwd
[root@localhost ~]# rpm -V pam
....L.... c /etc/pam.d/fingerprint-auth
....L.... c /etc/pam.d/password-auth
....L.... c /etc/pam.d/postlogin
....L.... c /etc/pam.d/smartcard-auth
....L.... c /etc/pam.d/system-auth
[root@localhost ~]#

[sumit-bose]

Hi,

this looks good, so next try, does your test user already has an entry in /etc/shadow? If created with useradd it should look like

test:!!:18550:0:99999:7:::

bye,
Sumit

[nora-pxh]

Hi,
Sorry for the late reply.
Yes，test user already has an entry in /etc/shadow.
[root@localhost ~]# cat /etc/shadow |grep test
test:$6$n31Uy8fpMGk/EbGQ$E5NTAcLRDoYVs4N37e.cxrZ1FtrKNQEeWxSRaN.a2PfEYxoNIrSKlhy76b/5/zMR4rwzsb1LLfmREI0iBhA7U0:18550:0:99999:7:::
[root@localhost ~]#

[sumit-bose]

Hi,

are there messages in the journal or in /var/log/secure at the time you are trying to change the password?

Does the password change work if you comment out password sufficient pam_sss.so use_authtok in /etc/pam.d/system-auth? I would expect that it fails as well.

bye,
Sumit

[nora-pxh]

Hi,

The message in /var/log/secure:
Oct 20 00:26:07 localhost passwd[918]: pam_unix(passwd:chauthtok): authentication failure; logname= uid=1000 euid=0 tty=pts/2 ruser= rhost= user=test

And I commented out assword sufficient pam_sss.so use_authtok in /etc/pam.d/system-auth,
the result is conformance to expectation.
[root@localhost ~]# grep "password sufficient" /etc/pam.d/system-auth
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
# password sufficient pam_sss.so use_authtok
[root@localhost ~]#
[test@localhost root]$ passwd
Changing password for user test.
Current password:
passwd: Authentication token manipulation error
[test@localhost root]$

And if you need further confirmation, please install Fedora ,it will make the investigation more efficient.
Thank you.

[sumit-bose]

Hi,

The message in /var/log/secure:
Oct 20 00:26:07 localhost passwd[918]: pam_unix(passwd:chauthtok): authentication failure; logname= uid=1000 euid=0 tty=pts/2 ruser= rhost= user=test

Hi,

for a user from /etc/passwd with a proper password hash in /etc/shadow pam_unix should not fail here if the password is correct and imo this is the reason for the odd behavior you are seeing.

And I commented out assword sufficient pam_sss.so use_authtok in /etc/pam.d/system-auth,
the result is conformance to expectation.
[root@localhost ~]# grep "password sufficient" /etc/pam.d/system-auth
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
# password sufficient pam_sss.so use_authtok
[root@localhost ~]#
[test@localhost root]$ passwd
Changing password for user test.
Current password:
passwd: Authentication token manipulation error
[test@localhost root]$

And if you need further confirmation, please install Fedora ,it will make the investigation more efficient.

I'm using a dedicated Fedora 33 VM since you've opened the ticket trying to reproduce your issue but it is working as expected for me:

[root@f33 vagrant]# su localuser
[localuser@f33 vagrant]$ cat /etc/fedora-release 
Fedora release 33 (Thirty Three)
[localuser@f33 vagrant]$ grep localuser /etc/passwd
localuser:x:1001:1001::/home/localuser:/bin/bash
[localuser@f33 vagrant]$ passwd
Changing password for user localuser.
Current password: 
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.

bye,
Sumit

Thank you.

[nora-pxh]

Hi，
Sorry, I didn’t make it clear.
The input password must be wrong if you reproduce the issue.

[sumit-bose]

Hi,

thanks, now it make sense. This was also reported in https://bugzilla.redhat.com/show_bug.cgi?id=1659100 and the reason is that SSSD does not properly check if some other module has already asked for the old password.

@justin-stephenson, I think you can use this as the upstream-ticket for the issue. Do you want to add the link to the bugzilla ticket or shall I?

bye,
Sumit

[nora-pxh]

Hi, @sumit-bose @justin-stephenson
Excuse me，when do you fix this issue？

[nora-pxh]

@sumit-bose @justin-stephenson
Hi, the result will be right if we add use_first_pass in /etc/pam.d/system-auth. And the configure is from authselect package. Would you put it to the community of authselect ?
-password sufficient pam_sss.so use_authtok use_first_pass

[sumit-bose]

@sumit-bose @justin-stephenson
Hi, the result will be right if we add use_first_pass in /etc/pam.d/system-auth. And the configure is from authselect package. Would you put it to the community of authselect ?
-password sufficient pam_sss.so use_authtok use_first_pass

Hi,

unfortunately this is only a workaround if you only have local users. If SSSD manages non-local users, e.g. user from LDAP or AD, then using use_first_pass will break password changes for the non-local users. Since pam_unix will not ask for the current password of non-local users and pam_sss would expect that another module already requests the current password in the end no module will ask for the current password of non-local users.

So the issue needs a fix in pam_sss.

bye,
Sumit

[alexey-tikhonov]

Will be handled via authselect/authselect#338 / authselect/authselect#344