Red Hat Bugzilla – Bug 4035
adduser/useradd command has undocumented option which does the wrong thing
Last modified: 2015-08-28 01:24:58 EDT
The adduser/useradd command specifies in the usage/'adduser
-h' output that one may use the '-p' option to specify a
password string for the user account being created. This
option is not documented anywhere in either the man page
*or* the source code.
In addition, it does completely the wrong thing when used.
It should (IMO) use the string provided as input to an
encryption function which will then place the encrypted
password and Salt into the passwd/shadow file. Instead, it
does nothing with this string other than place this
plaintext into the passwd/shadow file. If the user provides
a plaintext string, then that's what gets entered in to the
file. Things work fine if one provides an encrypted
password to begin with, but there's no way to know that is
what one is *supposed* to do, since there's no documentation
on the option!
I recommend 2 things:
1. Document the proper use of the -p option
2. Provide a way to specify both a plaintext passwd
string *and* an encrypted string.
I have verified this to be true on a standard 6.0 install. I am
assigning it to a developer for further review.
How can an undocumented feature do the WRONG thing?!
The argument for the -p is the encrypted string, period.
------- Additional Comments From 07/15/99 14:07 -------
I have no problem with the -p option only taking an encrypted string,
I have a problem with the fact that it's use is in no way documented
*anywhere*. Therefore it is not obvious nor intuitive that the string
argument to the -p option is *supposed* to be encrypted. The fact
that it takes any string and just places it into the passwd/shadow
file is wrong. If the person mistakenly places a string that is
plaintext on the command line, there is no error checking what-so-ever
to ensure it is, in fact, an encrypted string. If a plaintext string
gets placed into the passwd/shadow files (which is does currently)
that account will never be capable of being logged into, since the
string in the file is assumed to be encrypted. Therefore, no matter
what the user types for a password, nothing will ever encrypt to match
what's in the file.
Commit pushed to master at https://github.com/openshift/origin
Fix for issue #4035 - internally generated router keys are not unique.
(In reply to openshift-github-bot from comment #3)
> Commit pushed to master at https://github.com/openshift/origin
> Fix for issue #4035 - internally generated router keys are not unique.
Go HOME, openshift-github-bot, You Are Drunk (or whomever programmed you was).