Description of problem: IdM does not check Minimum life of password when performing password changing, if a very high minlife value is set. ========== $ ipa pwpolicy-show --user=bob Group: non_expired_passwd_group Min lifetime (hours): 99999 Grace login limit: -1 [bob@node-0 ~]$ passwd Changing password for user bob. Current Password: New password: Retype new password: Password change failed. Server message: Current password's minimum life has not expired Password not changed. passwd: Authentication token manipulation error ========== Change lifetime to 10x larger to previous run: ========== [bob@node-0 ~]$ ipa pwpolicy-show --user=bob Group: non_expired_passwd_group Min lifetime (hours): 999999 Grace login limit: -1 [bob@node-0 ~]$ passwd Changing password for user bob. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. Version-Release number of selected component (if applicable): How reproducible: 100% Actual results: Password changing is allowed even if age of password is within minlife. Expected results: 1. IdM checks acceptable range of integer when adding/modifying a password policy, and rejects ridiculously high values, or 2. IdM enforces password policy for whatever minlife value saved in policy. Additional info:
Sounds like an integer overflow. What is the use-case for using a huge case for minimum lifetime? Is it to disallow users from changing their own passwords?
> What is the use-case for using a huge case for minimum lifetime? Is it to disallow users from changing their own passwords? Yes, initially I was testing if it would be a possible option. Regardless what the use-case is, validation should be performed when either: (1) value is set in pwpolicy, or (2) user is changing password.