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.
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.
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.
Fixed in UPSTREAM CVS.
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.
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.