Bug 139593 - (IT_54285) pam overflows password age when chage maxdays value is set to 0x7fffffff
pam overflows password age when chage maxdays value is set to 0x7fffffff
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: pam (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Jay Turner
Depends On:
  Show dependency treegraph
Reported: 2004-11-16 16:02 EST by Neil Horman
Modified: 2015-01-07 19:08 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-09-08 13:05:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch to cast comparisons of currentdays and sp_* values to unsigned long (1.23 KB, patch)
2004-11-16 16:07 EST, Neil Horman
no flags Details | Diff
Patch applied to upstream (2.33 KB, patch)
2005-01-06 04:38 EST, Tomas Mraz
no flags Details | Diff

  None (edit)
Description Neil Horman 2004-11-16 16:02:06 EST
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):

How reproducible:

Steps to Reproduce:
1.chage -M 2147483647 <user>
2.login as that user
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 16:07:25 EST
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 02:59:22 EST
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 04:43:50 EST

Comment 8 Tomas Mraz 2005-01-06 04:38:38 EST
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 13:05:19 EDT
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. 

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