Bug 4035

Summary:	adduser/useradd command has undocumented option which does the wrong thing
Product:	[Retired] Red Hat Linux	Reporter:	plussier
Component:	shadow-utils	Assignee:	Cristian Gafton <gafton>
Status:	CLOSED NEXTRELEASE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	6.0	CC:	dmartin
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	1999-07-15 16:44:18 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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.

Thanks,

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

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 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).