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. Thanks,
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 https://github.com/openshift/origin/commit/b70701335543115b7ec3bfbd2f8475cae2c1d104 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 > > https://github.com/openshift/origin/commit/ > b70701335543115b7ec3bfbd2f8475cae2c1d104 > Fix for issue #4035 - internally generated router keys are not unique. Go HOME, openshift-github-bot, You Are Drunk (or whomever programmed you was).