Bug 4035 - adduser/useradd command has undocumented option which does the wrong thing
adduser/useradd command has undocumented option which does the wrong thing
Status: CLOSED NEXTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: shadow-utils (Show other bugs)
6.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Cristian Gafton
: Security
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-07-14 13:06 EDT by plussier
Modified: 2015-08-28 01:24 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-07-15 12:44:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description plussier 1999-07-14 13:06:24 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,
Comment 1 David Lawrence 1999-07-14 14:11:59 EDT
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 12:44:59 EDT
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 17:02:26 EDT
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.
Comment 4 Cristian Gafton 2015-08-28 01:24:58 EDT
(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.