This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 3078 - Can't log back in
Can't log back in
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: xscreensaver (Show other bugs)
6.0
i386 Linux
high Severity medium
: ---
: ---
Assigned To: Cristian Gafton
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-05-26 19:07 EDT by jjd202
Modified: 2008-05-01 11:37 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-06-22 15:51:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description jjd202 1999-05-26 19:07:31 EDT
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 19:18:59 EDT
Try setting your password to a known string. Perhaps you have caps
lock on ...
Comment 2 jjd202 1999-05-27 17:46:59 EDT
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 15:19:59 EDT
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 17:13:59 EDT
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.
Comment 5 Bill Nottingham 1999-06-17 17:40:59 EDT
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
Comment 6 Bill Nottingham 1999-06-21 14:41:59 EDT
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 08:17:59 EDT
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.
Comment 8 Cristian Gafton 1999-06-22 15:51:59 EDT
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 05:51:59 EDT
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.