Bug 138937 - Unable to login to NIS machine with new glibc
Summary: Unable to login to NIS machine with new glibc
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc   
(Show other bugs)
Version: 2
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-12 00:18 UTC by Phil Anderson
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-12 20:58:10 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Phil Anderson 2004-11-12 00:18:52 UTC
Description of problem:
Since applying the latest glibc patch for FC2, I am unable to ssh into
any of my machines which are using NIS for authentication.  Logging in
as root works fine.

I get:
$ ssh op17
Connection to op17 closed by remote host.
Connection to op17 closed.
$

/var/log/secure gets the line:
fatal: PAM session setup failed[6]: Permission denied

I'm not sure if i'm able to log in at the console or not, as I'm a 24
hour flight away from having physical access to the machine!

I tried restarting and disabling nscd but that didn't help.


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

How reproducible:
Always

Steps to Reproduce:
1. Update to latest glibc
2. ssh in to a NIS machine
    

Additional info:

Comment 1 Phil Anderson 2004-11-12 20:58:10 UTC
A reboot after applying the glibc update fixed the problem.

Comment 2 Jakub Jelinek 2004-11-12 21:05:04 UTC
glibc upgrade only restarts sshd, so that one can get in and restart other services or reboot.  The thing is if interface between NSS modules and libc
or among NSS modules changes (that happens quite frequently), already running
daemons that after upgrade dlopen some NSS module are suddenly in inconsistent
state.


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