Bug 88127 - pam_unix should attempt to change both local and NIS passwords
pam_unix should attempt to change both local and NIS passwords
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: passwd (Show other bugs)
rawhide
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-06 09:08 EDT by greg hosler
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version: pam-0.79-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-08 07:43:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description greg hosler 2003-04-06 09:08:30 EDT
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:
Always

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 15:38:49 EDT
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 06:48:08 EDT
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-21 21:56:11 EDT
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 15:15:15 EST
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 08:19:30 EDT
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 07:43:52 EDT
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.