Bug 198160 - Should have hash files for lastlog and faillog
Should have hash files for lastlog and faillog
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: pam (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-10 08:28 EDT by Russell Coker
Modified: 2010-12-06 06:16 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-12-06 06:16:11 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Russell Coker 2006-07-10 08:28:42 EDT
The lastlog and faillog files deliver inadequate performance when there are 
UID numbers in the >500,000,000 range.  A test on a Pentium-M 1.7GHz showed 
the "faillog" program taking over a minute of CPU time.

faillog is in the shadow-utils package but I'm filing the bug report against 
pam because of pam_tally.so and other modules that use it.

A hacky solution would be to have the same format of the faillog and lastlog 
files (with holes) but to have a hash table in a separate file that indicates 
which parts of the files are not holes.

I think that the best long-term solution is to migrate to a new file format 
and break compatibility (as we did with utmp).
Comment 1 David Tonhofer 2009-01-18 18:08:25 EST
I second the motion to have a non-sparse representation of "faillog". For problems with the sparse representation of "lastlog", see bug#146214.
Comment 2 Tomas Mraz 2010-12-06 06:16:11 EST
pam_faillock uses a different data structure - a file per user in a /var/run/faillock directory. This should be reasonably scalable.

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