Bug 476219
Summary: | pam tally needs to track per user failed attempts | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 5 | Reporter: | Steve Grubb <sgrubb> | ||||
Component: | pam | Assignee: | Tomas Mraz <tmraz> | ||||
Status: | CLOSED NEXTRELEASE | QA Contact: | BaseOS QE <qe-baseos-auto> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | high | ||||||
Version: | 5.3 | Keywords: | FutureFeature | ||||
Target Milestone: | rc | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Enhancement | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2012-03-05 16:32:00 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
Steve Grubb
2008-12-12 15:33:00 UTC
Created attachment 411370 [details]
pam_tally3 time-based account lockout threshold
Implements pam_tally3.so module. This a feature addition to pam_tally2 which implements a time-based account lockout threshold. After a specified amount of time, the account counter will be reset.
The problem with pam_tally3 (and pam_tally2 as well) is that it contains races. Multiple simultaneous log-in attempts will cause false lockouts in case the logins would be succesfull otherwise or in other cases the count of failed attempts might be lower than the actual amount. In case of pam_tally3 that means that sometimes the fail time records might be lost. I am also not too fond of adding a separate module for this. If the races are deemed not to be serious then we might just add a separate file with the fail time records with fixed record length per user as in the current tallylog file. If we'd like to at least partially solve the problem with races then a format similar to btmp could be used. This of course brings the problem with potentially slowing the logins as the btmp file grows and creates a problem with the need to rotate the file. The rotation would be complicated because during the rotation the old events could be lost. The third option perhaps the most accurate one would be to use some kind of database (SQLite?) for storing the data. However this is really heavyweight solution. We have pam_faillock now in RHEL-6 which solves the problem of tracking last n-attempts per user and also solves the race problem by using different PAM configuration and different storage of the data. |