Bug 11201 - PAM won't accept root's password
Summary: PAM won't accept root's password
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam   
(Show other bugs)
Version: 6.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2000-05-03 16:10 UTC by bhadley
Modified: 2007-04-18 16:26 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-04-14 18:45:26 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description bhadley 2000-05-03 16:10:44 UTC
After installing Red Hat 6.2 PAM worked just fine.  For instance, as a
normal user I could start up the up2date program and I would then be
prompted for root's password.  I would enter root's password and it would
then bring up the program.

The problem came immediately after upgrading my kernel with Red Hat's new
kernel listed in its errata page.  I just used rpm -Uvh to upgrade the
kernel (I was being brave) and after the upgrade PAM stopped working
correctly.  Now as a normal user if I try to bring up the up2date
program PAM prompts me with the password box but after I type in root's
password the password box goes away and no program is loaded.  I've tried
this over and over again with different programs and making sure I type in
root's password correctly but it never works.

I've looked through a lot of documentation on PAM and I couldn't find any
reference to this problem or any type of setting that may have changed that
would cause this.

Comment 1 bhadley 2000-05-04 19:54:59 UTC
I forgot to add this about my problem with PAM on Red Hat 6.2.

I added the debug argument to one of my PAM programs (up2date) and got the
following error messages when I tried to run up2date as a normal user and then
typed in root's password when PAM prompted me:

From /var/log/messages:
May  4 14:16:41 panaka pam_xauth[1110]: call_xauth: setuid to 500
for /usr/X11R6/bin/xauth with incoming (null)
May  4 14:16:41 panaka pam_xauth[1109]: _pam_xauth: xauth missing display

From /var/log/secure:
May  4 14:16:41 panaka pam_xauth[1109]: _args_init: getlogin failed

I hope this helps.  Again, I made absolutely sure I was typing in the right
password each time I tried this.

Comment 2 Cristian Gafton 2000-05-22 15:36:59 UTC
assigned to nalin

Comment 3 Nalin Dahyabhai 2000-06-10 21:13:04 UTC
Sounds like your naming service setup has gotten a little messed up.  Do the
"getent passwd root" and "getent passwd <yourlogin>" commands return any
results?  What are the contents of the PAM configuration file for up2date
(/etc/pam.d/up2date)?  Are you still able to use other programs that prompt for
the root password?

Comment 4 Simon Anderson 2000-07-27 16:11:03 UTC
su - root is completely broken on two of our systems, (RH6.2) independently on
the same day.

We don't use NIS but we do use shadowing. We have upgraded the package to
Pam-0.72-20 and made changes to the configuration files after reading through
the documentation.  We have checked that the various allow/deny files are
correct and that passwd and shadow are correct.

As far as we can see this is bug present in recent versions of this package and
not a configuration issue.

We are Solaris S/A's looking to farm out some of our low end services to Linux
but this is a real show stopper.  

Is this sort of problem common to Linux or is it particular to the RedHat
distribution?  Is RedHat more of an alternative to windows than a real choice
for production systems? Is there a distribution which is more robust?

Comment 5 Nalin Dahyabhai 2000-08-07 22:00:14 UTC
Which configuration files were changed?  I'm not aware that any of them would
have required altering in concert with the PAM package update.  The kernel
update should not have required modifications beyond the /etc/lilo.conf file
used by the kernel loader.

Comment 6 Jay Turner 2003-04-14 18:45:26 UTC
Closing out due to bit-rot.

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