Bug 31342 - /usr/lib64/security/pam_cracklib.so not found
Summary: /usr/lib64/security/pam_cracklib.so not found
Status: RESOLVED WORKSFORME
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: All Packagers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-12-30 20:36 CET by Lewis Smith
Modified: 2023-01-04 20:37 CET (History)
3 users (show)

See Also:
Source RPM: pam-1.5.2-2.mga9.src.rpm
CVE:
Status comment:


Attachments

Description Lewis Smith 2022-12-30 20:36:42 CET
Description of problem:
My system journal shows multiple occurences of for example:

mgaapplet-update-checker[3790]: running: urpmi.update -a
pkexec[3794]: PAM unable to dlopen(/usr/lib64/security/pam_cracklib.so): /usr/lib64/security/pam_cracklib.so: cannot open shared object file: No such file or directory
pkexec[3794]: PAM adding faulty module: /usr/lib64/security/pam_cracklib.so
pkexec[3794]: pam_unix(polkit-1:session): session opened

but it is not just from mgaapplet/urpmi.update
No noticeable ill effects.

Version-Release number of selected component (if applicable):
pam-1.5.2-2.mga9

How reproducible:
It seems to be triggered from at least mgaapplet, shorewell, draknetcenter, urpmi.update.

 $ ls -l /usr/lib64/security/pam_cracklib*
ls: cannot access '/usr/lib64/security/pam_cracklib*': No such file or directory

Assigning globally as PAM is committed by various people.
Comment 1 Dave Hodgins 2022-12-30 20:53:11 CET
See bug 31287

I'm not currently seeing any journal messages related to cracklib.
Are you getting anything found from "grep -r cracklib /etc/pam.d/*"?
Are there any "*.rpmnew" files in /etc?

CC: (none) => davidwhodgins

Comment 2 Jani Välimaa 2022-12-31 15:00:59 CET
As mentioned in bug 31287 pam_pwquality replaced pam_cracklib. I think simply removing all pam_cracklib occurrences isn't what we really want.

According to pam_pwquality man page:
"This module can be plugged into the password stack of a given service to provide some plug-in strength-checking for passwords. The code was originally based on pam_cracklib module and the module is backwards compatible with its options."

CC: (none) => jani.valimaa

Comment 3 papoteur 2022-12-31 18:08:40 CET
What I have in my old cauldron virtual machine, but updated:
grep -R cracklib
security/pwquality.conf:# credits are not disabled which is the default). (See pam_cracklib manual.)
security/pwquality.conf:# Whether to check for the words from the cracklib dictionary.
security/pwquality.conf:# Path to the cracklib dictionaries. Default is to use the cracklib default.
netprofile/profiles/default/urpmi/var/lib/urpmi/names.Core Release:cracklib-dicts
netprofile/profiles/default/urpmi/var/lib/urpmi/names.Core Release:cracklib
pam.d/system-auth:password    required      pam_cracklib.so try_first_pass retry=3 minlen=4  dcredit=0  ucredit=0 
my.cnf.d/cracklib_password_check.cnf:plugin-load-add=cracklib_password_check.so

I got error in journal when trying to log with SSH before entering the password. The session opens successfully.
déc. 31 16:13:26 localhost sshd[49096]: PAM unable to dlopen(/usr/lib64/security/pam_cracklib.so): /usr/lib64/security/pam_cracklib.so: cannot open shared object file: No such file or directory                                                                                                                                                                                           
déc. 31 16:13:26 localhost sshd[49096]: PAM adding faulty module: /usr/lib64/security/pam_cracklib.so
déc. 31 16:13:33 localhost sshd[49096]: Accepted keyboard-interactive/pam for yves from 192.168.1.17 port 45706 ssh2
déc. 31 16:13:33 localhost systemd-logind[739]: New session c7 of user yves.
déc. 31 16:13:33 localhost systemd[1]: Started session-c7.scope.
déc. 31 16:13:33 localhost sshd[49096]: pam_unix(sshd:session): session opened for user yves(uid=1000) by (uid=0)
déc. 31 16:13:33 localhost dbus-daemon[699]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.105' (uid=1000 pid=49125 comm="/usr/bin/hostnamectl --transient")
déc. 31 16:13:33 localhost systemd[1]: Starting systemd-hostnamed.service...
déc. 31 16:13:33 localhost dbus-daemon[699]: [system] Successfully activated service 'org.freedesktop.hostname1'
déc. 31 16:13:33 localhost systemd[1]: Started systemd-hostnamed.service.

CC: (none) => yves.brungard_mageia

Comment 4 papoteur 2022-12-31 18:17:30 CET
The content of my.cnf.d/cracklib_password_check.cnf is:
[mariadb]
plugin-load-add=cracklib_password_check.so

This file is provided by mariadb package. I presume it has to be replaced.
Comment 5 Jani Välimaa 2022-12-31 21:57:11 CET
(In reply to papoteur from comment #4)
> The content of my.cnf.d/cracklib_password_check.cnf is:
> [mariadb]
> plugin-load-add=cracklib_password_check.so
> 
> This file is provided by mariadb package. I presume it has to be replaced.

No, this is only for pam config files under /etc/pam.d/.
Comment 6 Lewis Smith 2023-01-02 20:25:45 CET
(In reply to Dave Hodgins from comment #1)
> See bug 31287
That is about GDM. Although I have that installed, LightDM is what is in use.

> Are you getting anything found from "grep -r cracklib /etc/pam.d/*"?
 $ sudo grep -r cracklib /etc/pam.d/*
/etc/pam.d/system-auth:password    required      pam_cracklib.so try_first_pass retry=3 minlen=4  dcredit=0  ucredit=0 

> Are there any "*.rpmnew" files in /etc?
 $ sudo find /etc -name '*.rpmnew'
/etc/shadow.rpmnew
/etc/fstab.rpmnew
/etc/pam.d/system-auth.rpmnew      ***
/etc/sddm.conf.rpmnew

I do tend to accept rpmnew offers, but imagined that they replaced the existing file and did not themselves persist as '.rpmnew'. I list both files below, not knowing which one is being used:

 $ sudo cat /etc/pam.d/system-auth.rpmnew
#%PAM-1.0
auth        required      pam_env.so
auth        sufficient    pam_unix.so try_first_pass nullok
auth        required      pam_deny.so

account     required      pam_unix.so

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     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so 

 $ sudo cat /etc/pam.d/system-auth
#%PAM-1.0

auth        required      pam_env.so
auth        sufficient    pam_unix.so try_first_pass likeauth nullok
auth        required      pam_deny.so

account     required      pam_unix.so

password    required      pam_cracklib.so try_first_pass retry=3 minlen=4  dcredit=0  ucredit=0 
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     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
-session    optional      pam_systemd.so

$ sudo diff /etc/pam.d/system-auth /etc/pam.d/system-auth.rpmnew
2d1
< 
4c3
< auth        sufficient    pam_unix.so try_first_pass likeauth nullok
---
> auth        sufficient    pam_unix.so try_first_pass nullok
9c8
< password    required      pam_cracklib.so try_first_pass retry=3 minlen=4  dcredit=0  ucredit=0 
---
> password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
14a14
> -session     optional      pam_systemd.so
16d15
< -session    optional      pam_systemd.so

Using diff -w (ignore white space) gave a slightly different result at the end:
> password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
15d13
< session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
16a15
> session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
Comment 7 Dave Hodgins 2023-01-03 00:28:56 CET
The files with the .rpmnew suffix are not used.

In the case of /etc/pam.d/system-auth.rpmnew you should use it
to replace /etc/pam.d/system-auth as in
mv -f /etc/pam.d/system-auth.rpmnew /etc/pam.d/system-auth

In the case of /etc/shadow.rpmnew and the one for fstab, delete or just
ignore the .rpmnew files as replacing the existing ones would be really bad
for the next reboot or login. :-)

In the case of /etc/sddm.conf.rpmnew, it depends on what if any changes
you've made to sddm.conf. It's safe to delete or ignore that rpmnew file
if sddm is working the way you want it.

There is no one size fits all for how to handle.rpmnew files, which is why
it can't be automated.
Comment 8 Lewis Smith 2023-01-04 20:30:13 CET
Thanks for your advice, particularly about /etc/pam.d/system-auth; and see whether that changes anything. Need to re-boot...
Comment 9 Lewis Smith 2023-01-04 20:37:01 CET
Bingo! Well done Dave.
After updating /etc/pam.d/system-auth and re-booting, there is no mention of "pam_cracklib.so" in the journal at all.

We do get bugs of this nature, sometimes just one error message; so it was worth the hassle.

Resolution: (none) => WORKSFORME
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.