Hide Forgot
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 =--=
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 =--=
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 =-=
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
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.
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.
Fixed in upstream CVS. (Without the comment #5.)
*** Bug 69547 has been marked as a duplicate of this bug. ***
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.
Re comment #12: I've decided not to do that to be in sync with upstream pam.
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
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