Bug 115309

Summary: NIS password changes are attempted before local user
Product: Red Hat Enterprise Linux 2.1 Reporter: Bryce <root>
Component: pamAssignee: Tomas Mraz <tmraz>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 2.1CC: k.georgiou, marc_soft, orion, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHBA-2005-091 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-04-28 15:39:36 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 132991    
Attachments:
Description Flags
ddd session in pam_dispatch.c. When h->func = pam_sm_chauthtok -> retval=24 none

Description Bryce 2004-02-10 16:01:12 UTC 
Description of problem:

Local user password changes when in a NIS enviroment are not working
as they USED to in AS2.1

Given two machines (server/client)
If the master has a NIS entry for a user say joe_pleb
and the client has a LOCAL user entry for joe_pleb
then when the user or root try to change the LOCAL user's password on
the CLIENT, passwd makes calls to PAM to request authentication at
which point it try's to change the NIS server user's passwd instead of
the LOCAL user passwd.

This is wrong and is preventing a large scale deployment of AS3. 
 
Version-Release number of selected component (if applicable):

AS2.1/RH9 v's AS3/FC1

How reproducible:

As mentioned above,.. just setup a server/client NIS setup
create a LOCAL user on the client

(extract from passwd file):
 joe_pleb:x:564:564::/home/joe_pleb:/bin/bash
 +::::::


Steps to Reproduce:
1. change passwd for user joe_pleb on server (ok)
2. change passwd for LOCAL user joe_pleb on client (FAIL)
  
Actual results:

[root@dhcppc1 passwd-0.68]# ypwhich
emerald

[root@dhcppc1 passwd-0.68]# ./passwd dev10
Changing password for user dev10.
New password: 
Retype new password: 
RPC: Can't encode arguments
The password has not been changed on emerald.

Expected results:

(NOTE: ypbind was not running so it couldn't do a NIS lookup/change)
[root@dhcppc1 passwd-0.68]# ./passwd dev10
Changing password for user dev10.
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.


Additional info:

Now I've done a load of testing as to try and work out whats going on
but gdb isn't terribly stable when tracing through PAM.

I think I've managed to discount the libuser vs libpwdb change as
being a red herring, as rebuilding libpwdb and AS2.1's passwd on a AS3
system shows up the same issue. So that really only leaves PAM and
possibly glibc.

I'm including a gif of a ddd debugging session showing where the
failure occurs. Unfortunately rerunning to get to the same point
always segv's gdb 8/

Phil
=--=
Comment 1 Bryce 2004-02-10 16:03:49 UTC 
Created attachment 97557 [details]
ddd session in pam_dispatch.c. When h->func = pam_sm_chauthtok -> retval=24 

It's difficult to debug this because gdb keeps segving for me about here

Phil
=--=
Comment 2 Bryce 2004-02-10 16:47:15 UTC 
I've not tested it myself but I've been told this wasn't an issue in
the AS3 beta - Red Hat Enterprise Linux release 2.9.03 (Taroon) should
anyone happen to have the src rpms from that kicking around and like
to do some regression comparisons

Phil
=-=
Comment 3 Bryce 2004-02-12 16:30:42 UTC 
FIX:

krafthefer pointed out that the /etc/pam.d/system-auth in RH9 and AS3
are differnet by virtue of having nis appended as an option on the
password sufficent line.

Hum I spent 1/2 a day regression testing this theory (removal of the
nis option on "password    sufficient" in  /etc/pam.d/system-auth) and
this indeed does appear at face value to do the trick.

I've tried a few other tricks a pieces that should work ad continye to
work when this action is taken, however, I cannot guarentee that that
is a 100% fix for the issue but it looks good from here.

NOTE1: this option is present in FC1 as well probably FC2 test1 as
well. Quite where, why or what appended it is an unknown for now. FC1
has the same issue.

NOTE2: it's vitally important in testing when changing NIS information
to remake the yp maps in /var/yp (just type make in that directory)
... Not that I forgot once or twice myself and went around cursing,
you understand <innocent whistle>

Phil
=--=

Summary: edit /etc/pam.d/system-auth and remove the nis option on the
"password sufficent" line
Comment 4 Tomas Mraz 2004-11-09 10:37:49 UTC 
If you remove the nis option passwd won't change NIS passwords at all
even for non-local users.

The problem is that the order of conditions when changing passwords in
the pam_unix module is that it first asks if the user is in NIS and
then only if it isn't it tries local /etc/passwd.

To solve this bug the order of these should be switched probably but
I'm afraid of regressions.
Comment 5 Tomas Mraz 2004-11-09 11:08:58 UTC 
The other question is if PAM should try to change both passwords if
the user info is both in NIS and in local /etc/passwd.
Comment 6 Tomas Mraz 2004-11-10 09:42:36 UTC 
Fixed in upstream CVS. (Without the comment #5.)
Comment 7 Tomas Mraz 2004-11-10 09:46:29 UTC 
*** Bug 69547 has been marked as a duplicate of this bug. ***
Comment 12 Orion Poplawski 2005-01-25 17:51:35 UTC 
I vote for password being changed in both.  I've maintained a local
patch for a while to do this.  We need for laptop users.  Laptops need
to have a local user so people can long in when they are off the
network.  But when on the network they use the NIS password.  It's
convenient to only have to change it in one location.
Comment 13 Tomas Mraz 2005-01-26 08:29:51 UTC 
Re comment #12: I've decided not to do that to be in sync with
upstream pam.
Comment 14 John Flanagan 2005-04-28 15:39:36 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-064.html
Comment 15 Tim Powers 2005-05-18 14:49:10 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2005-062.html