Bug 1654542

Works for me on Fedora 29 Workstation running inside QEMU/KVM.
(ISO file: Fedora-Workstation-Live-x86_64-29-1.2.iso)

[jkucera@localhost-live ~]$ sudo useradd -m foouser1
[jkucera@localhost-live ~]$ sudo passwd foouser1
Changing password for user foouser1.
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.
[jkucera@localhost-live ~]$

The password was 13 characters long containing lowercase and uppercase letters, digits, and special characters. Also works correctly with simple passwords.

Installed passwd-0.80-4.fc29 dependencies:
pam-1.3.1-3.fc29
audit-3.0-0.4.20180831git0047a6c.fc29
glibc-2.28-9.fc29
glib2-2.58.1-1.fc29
popt-1.16-15.fc29
libselinux-2.8-4.fc29
libuser-0.62-18.fc29

Reopening.

(In reply to Jiri Kucera from comment #1)
> The password was 13 characters long containing lowercase and uppercase
> letters, digits, and special characters. Also works correctly with simple
> passwords.
You seem to have missed, I don't even get a passwd prompt.

That said, I feel you are vastly understimating this bugs seriousness. It renders F29 unusable!

Ralf, can you please strace the hanging passwd command to see where it hangs?

What is your /etc/pam.d/passwd content and the content of included/substacked pam config files?

(In reply to Tomas Mraz from comment #3)
> Ralf, can you please strace the hanging passwd command to see where it hangs?
>
> What is your /etc/pam.d/passwd content and the content of
> included/substacked pam config files?
I can provide these infos if needed, but ...

... meanwhile, I am pretty sure, the cause is in pam, rsp. in Fedora's handling of the config-files below /etc/pam.d.

Rationale:
- Today, an update to the pam-package has landed.

- On a machine (the last of my machines not using authselect), which had been upgraded to fc29, some of the pam.d/* updates landed as *.rpmorg

- Investigating the cause, showed this machine was using pam.d/*-ac files, with the corresponding pam.d/* files being symlinks to the pam.d/*-ac files 
=> The pam.d/* updates were not applied.

On this machine, moving the pam.d/*.rpmorg to pam.d/*-ac immediate made "passwd <user>" functional again.

My conclusion:
* Upgrading to f29 doesn't update pam.d/* properly. 
* authconfig-based pam.d/*-configs which were working without visible flaws with older fedoras do not work anymore with f29.

On my other machines (which are using authselect's nis profile), I am now assuming (not yet tried to verify) authselects's nis-profile might be just "plain broken"/"incompatible to current pam".

On a broader scope, my problem with passwd is a symptom of the rpm-wise
messed-up situation of /etc/pam.d/* handling on upgrades/updates :(

It would still be interesting to see where the hang happens as I am not aware of any such incompatible changes in pam modules and the change can be a bug as well.

In regards to the problems with replacing the configuration generated by authconfig by something else - unfortunately there is no easy way to do that. Using authselect --force is the only thing that the authselect tool can provide but it of course might have also some unwanted effect as the features authselect provides are not a superset of that of authconfig.

(In reply to Tomas Mraz from comment #5)
> It would still be interesting to see where the hang happens as I am not
> aware of any such incompatible changes in pam modules and the change can be
> a bug as well.
OK, I'll attach an strace.

Another observation: Replacing the authselect generated /etc/pam.d/system-auth with the system-auth from the pam package renders passwd functional.


--- /etc/pam.d.authselect/system-auth	2018-12-01 08:01:28.126194495 +0100
+++ /etc/pam.d/system-auth	2018-12-06 19:01:44.977906491 +0100
@@ -1,23 +1,18 @@
-# Generated by authselect on Sat Dec  1 08:01:28 2018
-# Do not modify this file manually.
-
+#%PAM-1.0
+# This file is auto-generated.
+# User changes will be destroyed the next time authselect is run.
 auth        required                                     pam_env.so
-auth        required                                     pam_faildelay.so delay=2000000
-auth        sufficient                                   pam_unix.so nullok try_first_pass
-auth        requisite                                    pam_succeed_if.so uid >= 1000 quiet_success
+auth        sufficient    pam_unix.so try_first_pass nullok
 auth        required                                     pam_deny.so
 
-account     required                                     pam_unix.so broken_shadow
-account     sufficient                                   pam_localuser.so
-account     sufficient                                   pam_succeed_if.so uid < 1000 quiet
-account     required                                     pam_permit.so
+account     required      pam_unix.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 nis
+password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
+password    sufficient    pam_unix.so try_first_pass use_authtok nullok sha512 shadow
 password    required                                     pam_deny.so
 
 session     optional                                     pam_keyinit.so revoke
 session     required                                     pam_limits.so
-session     required                                     pam_systemd.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


> In regards to the problems with replacing the configuration generated by
> authconfig by something else - unfortunately there is no easy way to do
> that. Using authselect --force is the only thing that the authselect tool
> can provide but it of course might have also some unwanted effect as the
> features authselect provides are not a superset of that of authconfig.
All I can say, the current situation is unusable, plain broken and must be change. Technically, my gut feeling is, authselect should not use symlinks, but use files, instead.

Created attachment 1512219 [details]
strace -f -o passwd.strace passwd tester2

strace of a "hanging" passwd.

Authconfig used symlinks without problem for a very long time.

It looks like the problem is with the nis option of pam_unix. Is your system properly configured for nis?

I mean the rpmorg created on upgrade is not the real bug, it is irrelevant to this bug because the change of the pam configuration in the pam package was not related to NIS in any way.

Do you have the system really configured for NIS or why is the authselect nis profile used?

I cannot reproduce the hang with NIS profile on Fedora 28. I'm installing F29 now.

(In reply to Tomas Mraz from comment #8)
> It looks like the problem is with the nis option of pam_unix. Is your system
> properly configured for nis?
Well, the nis-pam configuration you see, are those authselect generates.

> I mean the rpmorg created on upgrade is not the real bug, it is irrelevant
BTW, these were *.rpmnew files - My fault, I didn't look carefully enough.

> to this bug because the change of the pam configuration in the pam package
> was not related to NIS in any way.
Well, 
- the dysfunctional pam-configs are those authselect generates for its nis-profile. 
- the functional pam-configs are those being shipped by the pam-package.

> Do you have the system really configured for NIS or why is the authselect
> nis profile used?
Yes. I am using nis (+autofs) and have been doing so without major problems since for ca. >20 years until f29. The shape of nis in f29 is well, ... poor. 

> I cannot reproduce the hang with NIS profile on Fedora 28. I'm installing
> F29 now.

The thing is I do not see anything wrong with the authselect config if you use nis. If the passwd works if you remove the nis option from pam_unix then the bug is actually either in pam_unix or in the way nis is configured on your systems but not in the authselect configuration.

The default pam configuration actually is not set up for nis.

Do you have users in nis? Does getent passwd <user-from-nis> work for you correctly?

With f30, this bug has hit me again.

You really don't want to know my opinion about this authselect stuff.

The origin of this hanger is the "nis" on the line being seen in the diff below. Changing it to nullok brings back passwd.

# diff -u /etc/authselect/system-auth.as /etc/authselect/system-auth
--- /etc/authselect/system-auth.as	2019-05-04 09:02:12.983560850 +0200
+++ /etc/authselect/system-auth	2019-05-04 10:22:04.608323856 +0200
@@ -13,7 +13,7 @@
 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 nis
+password    sufficient                                   pam_unix.so sha512 shadow nullok try_first_pass use_authtok nullok
 password    required                                     pam_deny.so
 
 session     optional                                     pam_keyinit.so revoke


Note1: system-auth.as is the original autoselect generated system-auth.
Note2: I am not sufficently familiar with pam to actually understand what I am doing nor what "nis" does.

The question is why the nis option makes the process to hang. It should not unless there is some problem with your NIS setup.

Basically the nis option causes pam_unix in password to check whether the user is in the nis user database.

Do you have users in nis? Does getent passwd <user-from-nis> work for you correctly?

This message is a reminder that Fedora 29 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '29'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 29 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Seems as if bugzilla has gone nuts.

Despite this bug was closed years ago, I am molested with needinfo requests.