Bug 65411 - xscreensaver fails to authorise on NIS machines
xscreensaver fails to authorise on NIS machines
Status: CLOSED CANTFIX
Product: Red Hat Linux
Classification: Retired
Component: xscreensaver (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-05-23 09:48 EDT by Peter Colijn
Modified: 2007-04-18 12:42 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-18 12:30:15 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Peter Colijn 2002-05-23 09:48:29 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.0 (X11; Linux i686; U;) Gecko/20020408

Description of problem:
When using xscreensaver to lock a machine that is connected to a network and
uses NIS for authentication, xscreensaver will not unlock when the user enters
his or her password, stating that the username/password combination is wrong.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Set up a RH 7.2 machine to connect to an NIS server (not NIS+, NIS).
2. Ensure that NIS is working on the client (i.e. users can log in through
normal means).
3. Lock the screen with xscreensaver (can be done in multiple ways; doesn't
matter how it's done).
4. Attempt to unlock the screen by moving the mouse and entering the user's
password.
	

Actual Results:  xscreensaver refuses to unlock the screen.

Expected Results:  xscreensaver should have unlocked the screen. (*very* sure
that the password entered is correct, checked caps-lock and all "normal" causes
of mistyping a password).

Additional info:
Comment 1 jmantel 2002-05-23 22:47:08 EDT
I too am seeing this.  Very odd. Nothing much to add here just that I really
don't want to have to build my own pam and xscreen saver just to get this to
work.  I have tried NIS in compat mode but that did nothing.  Once an answer is 
found a complete description of the setup would be great.  
(i.e. nsswitch.conf, pam files, password and shadow files, etc.)
Comment 2 jmantel 2002-05-30 21:50:39 EDT
Hey, I submitted a fix a while ago. But here it is again.
I rebuilt xscreensaver from the latest code base and it works as expected.
Now the only problem I have is getting it to act like the original does.
(i.e. when in run level 5, gdm, a user logs in and screensaver starts
automatically.  But after I install my rebuilt xscreensaver on top of the 
the original xscreensaver it does not start automatically.  The binaries
and libraries are in the same place but something about gnome or kde starting
up do not want to run my xscreenaver.  I have looked all around trying to find
how the original xscreensaver starts when someone logs in but I cannot seem to
reproduce that with my xscreensaver.  What gives?
Comment 3 Peter Colijn 2002-08-02 06:05:29 EDT
Found a solution. Change /etc/pam.d/xscreensaver to use pam_unix.so instead of
pam_stack.so; this is more of a workaround, since pam_stack.so *should* work.
However, this does make xscreensaver work as expected.
Comment 4 Bill Nottingham 2002-08-12 16:54:56 EDT
Nalin, any idea what's going on here?
Comment 5 Bill Nottingham 2002-08-12 17:18:30 EDT
What does your /etc/pam.d/system-auth look like?
Comment 6 Ray Strode [halfline] 2004-11-04 02:11:25 EST
If this bug is still relevant (which seems rather unlikely given its
age) it might be because xscreensaver's pam functions don't call
pam_acct_mgmt.
Comment 7 michael.mackey 2005-08-09 10:48:53 EDT
I've hit this problem with NIS/xscreensaver on Fedora 4 (both i686 and x86_64).
The problem is reproducible with vlock.  Strangely, following the failed user
authentication, vlock also fails root authentication.  Of course, root is not in
the NIS map.

Comment 8 Bill Nottingham 2006-08-07 15:05:21 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.
Comment 9 Bill Nottingham 2006-10-18 12:30:15 EDT
Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.

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