Red Hat Bugzilla – Bug 72852
mkpasswd does not work with yppasswd
Last modified: 2007-11-30 17:10:30 EST
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):
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]
Actual Results: Failed preliminary check by password service
Expected Results: the passwd of the user named should be changed and the passwd
used should be displayed on the screen.
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
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.
Here is the original bug report:
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.
Havill's expect-5.32.2-random.patch is still in
(has been since Jul 19 2001). So perhaps it is
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.
Cool. Thank you for your testing. :)
Don't suppose it is any better in newer versions of expect?
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.
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.
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.