If xscreensaver is used or I walk away from the terminal for a few minutes, the console locks up and requires a password to log back in. However, it will not accept the user's, root, or any other password as a valid entry. To get back in, I have to hard boot the entire system. From what I understand this is a BAD thing to do. I've already had to reinstall after corrupting my filesystem as a result of this. I'm using the Gnome/Enlightment window manager on a Micron Millenia 400 PC.
Try setting your password to a known string. Perhaps you have caps lock on ...
Tried both suggestions... still locks up. Is there a way to set the screensaver password from inside the GUI? I've already looked, but I couldn't find anything that relates to the screensaver besides the GNOME Control Center. I've even tried setting it to start after 0 minutes, however it still locks up after a period of time. Should I try installing an older version of the program... I have Red Hat 5.1 and 5.2.
Just wanted to add that xlock and vlock have the same problem... Could PAM be screwed up somehow??? ------- Additional Comments From 06/08/99 05:12 ------- We see the same problem for xlock, but only for NIS users.
Are the users that are causing the problems: a) NIS or b) shadow passwords or c) MD5 passowrds What does /etc/pam.d/xscreensaver say, and what are in the logs? (remember, unless you've specifically changed it, you can switch to a VC and log in as root...) ------- Additional Comments From 06/15/99 19:21 ------- I'm using shadow and MD5 passwords, /etc/pam.d/xscreensaver reads: #%PAM-1.0 auth required /lib/security/pam_pwdb.so shadow nullok I've done a reinstallation since the last time I was locked out... useful log messages need to be re-created.
what version of pam are you running? ------- Additional Comments From 06/21/99 09:25 ------- I'm using NIS and shadow passwords. # rpm -qa|grep pam pam-0.66-18 # cat /etc/pam.d/xscreensaver #%PAM-1.0 auth required /lib/security/pam_pwdb.so shadow nullok
Hm... if they're NIS users, whether or not you're using shadow passwords locally shouldn't matter. ypbind is still running on the affected box, correct? Out of curiosity, what happens if you do 'chmod a+s xscreensaver'? (warning: make sure you've installed the errata before you do this...)
I somehow figured out what is wrong: We are using NIS shadow passwords. The NIS server is IBM AIX <52> ypcat passwd|grep user user:##user:2146:20:user:/home/user:/usr/local/bin/tcsh The point is that using or not shadow passwords locally does matter! In our case, if shadow is not used locally, the xlock do not look in the /etc/shadow and so doesn't find the password for NIS users. If shadow is used locally, then xlock works fine also for the NIS users. Note that the login process (console login or telnetd) works correctly in any case. By the way, mode 4755 for xscreensaver and xlock does not solve the problem. Hope this helps.
the user figured it out, it seems pwdb does not support shadow over NIS as done by IBM AIX. ------- Additional Comments From 06/22/99 16:42 ------- Hey... thanks for the help!!! It works now. I accidently ran a chmod 700 -R * in my root directory after I first installed RH6. From what I can figure this is probably what screwed things up. For some reason I had to do a complete reinstallation to get it right. Thanks again!
I don't understand why this won't be fixed: Login looks in the /etc/shadow file (which is on the localhost) whenever it finds a shadow password, no matter if the user is NIS. And no matter if shadow passwords is used on the localhost for local users (at least root and some sys defined users have entries in the local passwd file). I believe xlock should behave the same. Check for the /etc/shadow even if shadow is not used for local users; so that login and lock would behave in a coherent way.