Bug 139593 (IT_54285)

Summary: pam overflows password age when chage maxdays value is set to 0x7fffffff
Product: Red Hat Enterprise Linux 3 Reporter: Neil Horman <nhorman>
Component: pamAssignee: Tomas Mraz <tmraz>
Status: CLOSED DEFERRED QA Contact: Jay Turner <jturner>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: srevivo, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-09-08 17:05:19 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:
Attachments:
Description Flags
patch to cast comparisons of currentdays and sp_* values to unsigned long
none
Patch applied to upstream none

Description Neil Horman 2004-11-16 21:02:06 UTC 
Description of problem:
If a users password is set to 2147483647, subsequent logins (using
login) for the user cause the expired passwords routine to come up.
Once the user enters his old password, PAM returns:

"You must wait longer to change your password" and fails the login.

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

How reproducible:
always

Steps to Reproduce:
1.chage -M 2147483647 <user>
2.login as that user
3.
  
Actual results:
pam requests you enter a new password, and then fails.

Expected results:
user should be logged in.

Additional info:
This may also need fixing under RHEL2.1.  Haven't tested yet.
Comment 1 Neil Horman 2004-11-16 21:07:25 UTC 
Created attachment 106845 [details]
patch to cast comparisons of currentdays and sp_* values to unsigned long

This patch corrects this problem.  In the pam_unix_chauthtok function, the
maxdays, inactive and lastchange values are summed and compared to the
currentdays value.  Since sp_max, sp_lstchng, and sp_inact are signed long
integers (as is currentdays, which is typed as time_t), setting any one of the
sp_* values to 0x7fffffff will cause an overflow (unless the others are both
zero).	This overflow causes the comparison to evaluate incorrectly, causing
the described problem.	It seems to me that since we normally need currentdays
to be a time_t and the sp_* values to be signed integers, the easiest fix (and
I think the correct fix) would be to cast the rhs and lhs of these specific
comparisons to unsigned integers.  This patch makes that conversion in the
appropriate places.  Its been tested and works well.
Comment 2 Tomas Mraz 2004-11-17 07:59:22 UTC 
I'm sorry but this is NOTABUG. Any large value of -M will have the
desired effect of effectively disabling password expiration so there
is no need to set it to 0x7fffffff. As default there is 99999.

Note also that when time_t is 32bits there is no way how could you get
0x7fffffff as number of days anyway.
Comment 6 Tomas Mraz 2004-12-03 09:43:50 UTC 
Fixed in UPSTREAM CVS.
Comment 8 Tomas Mraz 2005-01-06 09:38:38 UTC 
Created attachment 109413 [details]
Patch applied to upstream

If the patch should be correct it must be more invasive than the previous one.

Note this patch was applied upstream.
Comment 13 Tomas Mraz 2005-09-08 17:05:19 UTC 
This problem will be resolved in a future major release of Red Hat Enterprise
Linux. Red Hat does not currently plan to provide a resolution for this in a Red
Hat Enterprise Linux update for currently deployed systems.

With the goal of minimizing risk of change for deployed systems, and in response
to customer and partner requirements, Red Hat takes a conservative approach when
evaluating changes for inclusion in maintenance updates for currently deployed
products. The primary objectives of update releases are to enable new hardware
platform support and to resolve critical defects.