Bug 61280

Summary:	pam-0.75-19 rejects NIS password >8 characters
Product:	[Retired] Red Hat Linux	Reporter:	ken_laird
Component:	pam	Assignee:	Nalin Dahyabhai <nalin>
Status:	CLOSED NOTABUG	QA Contact:	Aaron Brown <abrown>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.2
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2002-03-15 21:20:48 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 ken_laird 2002-03-15 21:20:44 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3-12smp i686)

Description of problem:
Installed out-of-box Redhat 7.2 on a box.  User with a 9 character password
complained that he couldn't login.  I applied the updated pam-0.75-19 errata
package along with the other two packages included in that errata.  Problem was
not fixed.
We are using an NIS password file. 
This user can login by just typing the first 8 characters of his password.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Use NIS password file with DES encryption.
2.Have user create a 9 character password.
3.Try logging in through KDE or via telnet.
	

Actual Results:  Login is rejected.

Expected Results:  pam should have ignored input characters beyond 8.

Additional info:

This problem was solved with earlier Redhat releases and is now back.  Despite
closing notation in another bug I saw in Bugzilla (Sorry, I don't have the
number readily available), the problem is not fixed.

Comment 1 ken_laird 2002-04-11 20:45:50 UTC

Further investigation revealed that this bug report  should be canceled.
The pam-unix module of pam-0.75-14 would reject 9 character passwords but that
is actually
fixed with pam-0.75-19.
The password rejection behavior occurs when a user with such a password tries to
login via kdm.
I will check into this some more and, if necessary, file a different bug report.