Bug 3078 - Can't log back in
Summary: Can't log back in
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xscreensaver
Version: 6.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-05-26 23:07 UTC by jjd202
Modified: 2008-05-01 15:37 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-06-22 19:51:58 UTC

Attachments (Terms of Use)

Description jjd202 1999-05-26 23:07:31 UTC
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.

Comment 1 Jeff Johnson 1999-05-26 23:18:59 UTC
Try setting your password to a known string. Perhaps you have caps
lock on ...

Comment 2 jjd202 1999-05-27 21:46:59 UTC
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.

Comment 3 jjd202 1999-06-05 19:19:59 UTC
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.

Comment 4 Bill Nottingham 1999-06-14 21:13:59 UTC
Are the users that are causing the problems:

a) NIS
b) shadow passwords
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:

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.

Comment 5 Bill Nottingham 1999-06-17 21:40:59 UTC
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

# cat /etc/pam.d/xscreensaver
auth       required     /lib/security/pam_pwdb.so shadow nullok

Comment 6 Bill Nottingham 1999-06-21 18:41:59 UTC
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...)

Comment 7 Anonymous 1999-06-22 12:17:59 UTC
I somehow figured out what is wrong:
We are using NIS shadow passwords. The NIS server is IBM AIX

<52> ypcat passwd|grep user

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
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

Hope this helps.

Comment 8 Cristian Gafton 1999-06-22 19:51:59 UTC
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!

Comment 9 Anonymous 1999-06-23 09:51:59 UTC
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.

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