Bug 4035 - adduser/useradd command has undocumented option which does the wrong thing
Summary: adduser/useradd command has undocumented option which does the wrong thing
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: shadow-utils
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Cristian Gafton
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 1999-07-14 17:06 UTC by plussier
Modified: 2015-08-28 05:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 1999-07-15 16:44:18 UTC

Attachments (Terms of Use)

Description plussier 1999-07-14 17:06:24 UTC
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.


Comment 1 David Lawrence 1999-07-14 18:11:59 UTC
I have verified this to be true on a standard 6.0 install. I am
assigning it to a developer for further review.

Comment 2 Cristian Gafton 1999-07-15 16:44:59 UTC
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.

Comment 3 openshift-github-bot 2015-08-21 21:02:26 UTC
Commit pushed to master at https://github.com/openshift/origin

Fix for issue #4035 - internally generated router keys are not unique.

Comment 4 Cristian Gafton 2015-08-28 05:24:58 UTC
(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).

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