I was trying to do some maintance to my /usr filesystem while in single user mode and I was unable to unmount it because it was busy. Looking into it I found the /bin/login process, via pam, has the files /usr/lib/libglib-1.2.so.0.0.10 and /usr/lib/libcrack.so.2.7 open. Tracing the pam.d files you'll find /usr/lib/libcrack.so.2.7 is used by pam_cracklib.so from /etc/pam.d/system-auth . If pam_cracklib is designed to check the password against dictionary words when you are setting your password with passwd (or similar tool) then why is it part of the login process via system-auth ? /usr/lib/libglib-1.2.so.0.0.10 is used by pam_console from /etc/pam.d/login . I'm not sure how to deal with pam_console in this case. I don't fully understand it well enough to say any more than it bothers me that I cannot fully admin my boxes in single user mode because of this. Staticially linking libglib into pam_console would be sufficent. As a work around one can comment out the pam_console line from their /etc/pam.d/login file and comment out the pam_cracklib line from theur /etc/pam.d/system-auth file. After that the admin would need to log out and back in to release any existing open files in /usr/lib
libcrack is used when setting the password, and last time I checked, you could not specify to to pam not to open all modules in the config file. This much with pam_stack is a bug pam side I guess. A fix could be to move cracklib, but I do not know what impact it will have on having the dicts in /usr/lib still (maybe nothing, as you will not be changing the password ?) ... For glib, you could then rather link in the static version like you suggested. I will look into this when I get time.
both suggestions have been incorporated long ago
