This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 72852 - mkpasswd does not work with yppasswd
mkpasswd does not work with yppasswd
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: expect (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Miloslav Trmač
:
Depends On:
Blocks: 141725 FC6Target
  Show dependency treegraph
 
Reported: 2002-08-28 09:30 EDT by akonstam
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-29 09:28:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description akonstam 2002-08-28 09:30:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
The mkpasswd does not work on the NIS server. Here is why:
1. On line 16 and 17 of mkpasswd it refers to /bin/yppasswd.
yppasswd is in /usr/bin so it is not found.
2. Ok we change the lines. When yppasswd runs as root it does not work the
way passwd runs as root. The latter only asks for the new passwd to be
typed twice. yppasswd required the root passwd to be entered before
the new passwds are entered. In mkpasswd  lines 193  and following the
appropriate passwd changing program is called. But the mkpasswd script
at that point has no provision for entering the root passwd so the
mkpasswd script fails.


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


How reproducible:
Always

Steps to Reproduce:
1.Have NIS running and yppasswd to be used to change passwd. ypbind is also
running on the server
2.su -  [on server]
3.mkpasswd username
	

Actual Results:   Failed preliminary check by password service
rh3RV0ky@

Expected Results:  the passwd of the user named should be changed and the passwd
used should be displayed on the screen.

Additional info:

Note however that when mkpasswd runs it does not find yppasswd so
it is passwd that is actually used. We can get expected results by stopping
ypbind since mkpasswd username will work if it is not running
since agin it is passwd username not yppasswd username that is actually running.
I can't figure out why yppasswd run as root should require you to enter the root
passwd.
Comment 1 Mike A. Harris 2002-09-25 07:32:10 EDT
mkpasswd is totally insecure and should be completely removed from
the distribution.  I've posted a bug report about this before, but
it possibly has been closed WONTFIX or something (I dunno).  The
program is NOT truely random.

It has a period of around 31000, and will only generate about that
many random passwords.  In a very short period of time, one person
on one computer can brute force attack a system which is using
mkpasswd to generate passwords.

A search of all bugzilla bug reports for "mkpasswd" should turn up
my report, and my script of proof for the above statements.
Comment 2 Mike A. Harris 2002-09-25 07:39:31 EDT
Here is the original bug report:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=9507

It claims it is fixed now.  I don't know what version as it is not
indicated.  I'll test the latest version however, and see how
truely random it is.
Comment 3 Jens Petersen 2002-12-11 00:39:03 EST
Havill's expect-5.32.2-random.patch is still in
(has been since Jul 19 2001).  So perhaps it is
better now.
Comment 4 Mike A. Harris 2002-12-11 05:57:36 EST
I just tested RHL 8.0 mkpasswd and it generated passwords for 2.5 hours in
a forkbomb.  ;o)  It was hard to get out of the accidental forkbomb but
I eventually did.  ;o)

Results:  418260 passwords generated, and 418260 were unique

In other words, no password was ever duplicated in over 418260 attempts.

I'd have to leave this going all night long to get better testing, but
I have a feeling it is much more secure now.
Comment 5 Jens Petersen 2002-12-12 01:31:13 EST
Cool.  Thank you for your testing. :)
Comment 6 Jens Petersen 2004-02-26 03:01:48 EST
Don't suppose it is any better in newer versions of expect?
Comment 7 akonstam 2004-02-26 09:31:55 EST
It is frustrating to take so long to get any definitive response for
this problem. makpasswd in RH 9 still uses yppasswd as a default with
the same problem. However, there is a parameter to change it to use
passwd. The locations of passwd and yppasswd are still wrong in the
script. With all these changes it still hangs up to 20% of the time in
an environment where mkpasswd is in a script that can be run by more
than one person and protected by the lockfile command. So mkfile is
still a problem.
Comment 8 Jens Petersen 2005-09-28 04:28:46 EDT
Sorry for leaving this so long.

My only concern if that since yp-tools seems to be installed by
default, fixing this will break mkpasswd for people not using
nis but with yp-tools installed.  Perhaps it would be better to
have two separate scripts: one for passwd and one for yppasswd?

I don't use yppasswd myself, but if you are able to generate a
mkyppasswd script I think I can add it to the expect package.
Comment 9 Miloslav Trmač 2006-08-29 09:28:23 EDT
I have sent upstream a patch that asks the user for root's password if
yppasswd is used.

I agree with comment #8 that using yppasswd by default is not desirable,
so not fixing the path in mkpasswd is probably better.

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