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.