sys-libs/pam-1.4.0-r1 does have changed pam configure flags: --disable-cracklib --disable-tally --disable-tally2 Thus all earlier pam ebuilds do install these pam libs whereas pam-1.4.0-r1 doesn't. This breaks any login when any of these pam libraries is in use after an upgrade to pam-1.4.0-r1, when these libraries are referenced in the /etc/pam.d configuration. Such a configuration change *MUST NOT* be hardcoded without any warning, use flags are in order. Reproducible: Always
pam pulls correct version of pambase withproper settings.
(In reply to Mikle Kolyada from comment #1) > pam pulls correct version of pambase withproper settings. So is this a pambase issue then? I've tried with 20200616 through 20200618, and they all fail ldap auth for me, while local logins are fine. journalctl lists: Jun 18 07:09:46 Rostia login[57932]: PAM adding faulty module: /lib64/security/pam_cracklib.so Jun 18 07:09:46 Rostia login[57932]: PAM unable to dlopen(/lib64/security/pam_cracklib.so): /lib64/security/pam_cracklib.so: cannot open shared object file: No such file or directory
(In reply to Brandon Penglase from comment #2) > (In reply to Mikle Kolyada from comment #1) > > pam pulls correct version of pambase withproper settings. > > So is this a pambase issue then? > I've tried with 20200616 through 20200618, and they all fail ldap auth for > me, while local logins are fine. > > journalctl lists: > > Jun 18 07:09:46 Rostia login[57932]: PAM adding faulty module: > /lib64/security/pam_cracklib.so > Jun 18 07:09:46 Rostia login[57932]: PAM unable to > dlopen(/lib64/security/pam_cracklib.so): /lib64/security/pam_cracklib.so: > cannot open shared object file: No such file or directory Sure they will, because pam_cracklib.so does not exist anymore. No, this is not the pambase's problem because cracklib does not exist anymore there as well. All past 3 releases had changes regarding how pam_faillock.so must function, nothing else.
