Bug 88127 - pam_unix should attempt to change both local and NIS passwords
Summary: pam_unix should attempt to change both local and NIS passwords
Alias: None
Product: Fedora
Classification: Fedora
Component: passwd
Version: rawhide
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Tomas Mraz
QA Contact: Mike McLean
Depends On:
TreeView+ depends on / blocked
Reported: 2003-04-06 13:08 UTC by greg hosler
Modified: 2007-11-30 22:10 UTC (History)
4 users (show)

Fixed In Version: pam-0.79-3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-04-08 11:43:52 UTC
Type: ---

Attachments (Terms of Use)

Description greg hosler 2003-04-06 13:08:30 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
Red Hat 9 NIS server, MD5 + Shadow passwords.

Password cannot be changed for users, either by the user, or by root.
This is true both on the NIS server itself, as well as NIS clients.

I tried 2 different fresh installs. reproduceable on both installations.

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

How reproducible:

Steps to Reproduce:
1. set up a NIS server
2. create a user
3. start up the necessary NIS services (ypbind, ypserv, yppasswdd)
4. try to change the password for a user.

Actual Results:  [root@tomboy root]# passwd greg
Changing password for user greg.
New password:
Retype new password:
RPC: Can't encode arguments
The password has not been changed on tomboy.nanocube.localdomain.
passwd: Failed preliminary check by password service

Expected Results:  password should be allowed to change

Additional info:

The only way to change a password, is as follows:
1) log onto the NIS server
2) stop ypbind
3) change the password
4) restart ypbind

Comment 1 Damian Menscher 2003-04-18 19:38:49 UTC
I've seen this also, under RH 7.3 and 8.0.  I even posted newsgroup article 
bE97a.3715$o7.39690@vixen.cso.uiuc.edu about it (groups.google for "redhat 
yppasswd menscher" to find).  Still trying to figure out a reasonable fix.

Comment 2 Gerald Teschl 2003-04-21 10:48:08 UTC
This problem is present since 7.x and there are several bug reports. The
following workaround works on 7.x and 8.0:

Turn off ypbind and disable nis in pam on the server. Then passwords can
be changed on both clients and server. However, changing the password
on the server will not automatically update the nis database.

You should also disabel yppasswd, since it will create crypt passwords even
if md5 is set.

Comment 3 Damian Menscher 2003-04-22 01:56:11 UTC
Ok, given that the proposed workaround is to not be an NIS server, and given 
that NIS service is considered basic functionality of a UNIX machine, I'd like 
to recommend that the priority/severity levels be raised to "high".  
Unfortunately only the original bug submitter can do that, so I'm asking that 
he do that.  Feel free to LART me if you think I'm being picky here, but I'm 
going to have to switch to a different distribution (or OS) if a fix (or 
reasonable workaround) can't be found.

Comment 4 marcuscrazy 2005-02-10 20:15:15 UTC
This is also happening in Fedora Core 3.
I spent quite a bit of time researching and implimenting NIS
(new to linux administration) to come to the final point and have to
consider a different resolution.  I think this should also be raised
to the hightest level.

Comment 5 Tomas Mraz 2005-04-07 12:19:30 UTC
I've made a couple of tests with FC3 and RHEL4 machines both as server or client.

To recap the problems I see and things which work for me:

Changing password on the machine with NIS server:
- pam<0.77-66.2:
   1. root cannot change user's password using passwd only by yppasswd
   passwd works fine for users

- pam>=0.77-66.2:
   2. passwd (by either user or root) changes only the /etc/shadow not the NIS
one - root must update the NIS db afterwards

Changing password on the client machine:
- pam<0.77-66.2:
   - user only in the local /etc/passwd,shadow - everything OK
   - user both in the local /etc/passwd,shadow and on the remote server 
       3. passwd tries to change the password in the remote server however it's
authenticated against the local - if the passwords differ the user cannot change
it's password
       4. root cannot change such user's password using passwd only yppasswd -
this changes only the NIS password, not the local one
   - user only on the remote server
       5. root cannot change such user's password using passwd only yppasswd
- pam>=0.77-66.2:
   - user only in the local /etc/passwd,shadow - everything OK
   - user both in the local /etc/passwd,shadow and on the remote server 
       6. passwd changes only the local password not on the remote server - this
will make them differ if they were the same before
       7. root will change such user's local password - again it can make it out
of sync with NIS password
   - user only on the remote server
       8. root cannot change such user's password using passwd only yppasswd

So we see that the update I've done in the pam-0.77-66.2 solved only some problems.

The remaining problems:
2. - can be solved only for user, if root changes the user's password he must
update the NIS db afterwards or he must use yppaswd (with it's deficiency of not
using the MD5 hash), the solution is to update both local and NIS passwords but
don't error if the NIS password update fails 
6. - can be solved by the same solution
7.,8. - this cannot be easily solved - the workaround is the root must first use
passwd to change the local password and then yppasswd to change the remote one

Comment 6 Tomas Mraz 2005-04-08 11:43:52 UTC
So the final solution is:
1. First try to update the NIS password
2. Regardless of its success or failure update the local password if the user is
in the local files.
3. Return success or failure based only on the latest change done.

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