Bug 141725 - mkpasswd tries to locate default passwd programs in wrong directory
mkpasswd tries to locate default passwd programs in wrong directory
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: expect (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
:
Depends On: 72852
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-03 06:30 EST by Need Real Name
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-12-20 15:01:19 EST
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 Need Real Name 2004-12-03 06:30:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3)
Gecko/20040922

Description of problem:
mkpasswd specifies default names and directories for the passwd program.
All the default programs (nispasswd, yppasswd and passwd) are listed
as being in directory /bin whereas they are in directory /usr/bin.  On
Solaris (where I have successfully used mkpasswd) /bin is a soft-link
to /usr/bin.  If mkpasswd does not find a program in the default
directories, it uses passwd and relies on the setting of $PATH.

Also note that on Solaris yppasswd and passwd are the same file (hard
link), whereas on Linux they are different programs and can give
different results.  If this problem is fixed (by changing the
directory for the default programs to /usr/bin), then (for my
configuration) mkpasswd fails when a userid is supplied as it finds
yppasswd and tries to use that.  On my configuration for userid root,
the command "passwd someuserid" fails but the command "yppasswd
someuserid" works though I have to supply the root password; mkpasswd
does not handle the request for the root password appropriately.

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

How reproducible:
Always

Steps to Reproduce:
1. Inspect mkpasswd code (for directory problem)
2. Try commands in "Actual results" section below for problem with
yppasswd (different in my case from passwd)
3.
    

Actual Results:  For my system configuration mkpasswd when used by
root fails whether it uses passwd or yppasswd internally.  When using
passwd, I get message:
# mkpasswd -v silly
spawn passwd silly
Changing password for user silly.
New password: ch4V>yp5N

Retype new password: 
RPC: Can't encode arguments
The password has not been changed on wyatt.gridpp.rl.ac.uk.
passwd: Failed preliminary check by password service
ch4V>yp5N
password for silly is ch4V>yp5N

When using a modified version of mkpasswd so that it finds yppasswd, I
get:

# bin/mkpasswd -v silly
spawn /usr/bin/yppasswd silly
Changing NIS account information for silly on wyatt.gridpp.rl.ac.uk.
Please enter root password:
Changing NIS password for silly on wyatt.gridpp.rl.ac.uk.
Please enter new password:
Please retype new password:
Error while changing the NIS password.
The NIS password has not been changed on wyatt.gridpp.rl.ac.uk.

password for silly is {sy6rQ2qR


Expected Results:  In either case the password for userid silly should
have been updated using the random string 

Additional info:

1. My configuration is using NIS; there may be a problem there that
prevents passwd working
2. Userid silly can update their own password from a NIS client
Comment 3 Jens Petersen 2005-09-29 23:54:39 EDT
This needs to be fixed in Fedora Core development at least
and RHEL4 before it can be done for RHEL3.

If you want to contribute a patch for that please read
bug 72852 and attach it there. Thanks.
Comment 4 Miloslav Trmač 2006-08-29 10:39:03 EDT
A patch implementing yppasswd support was sent upstream.
Comment 6 RHEL Product and Program Management 2006-12-20 15:01:19 EST
Product Management has reviewed and declined this request.  You may appeal this
decision by reopening this request. 

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