Bug 1808112

Summary: The /var/log/tallylog file becomes very large when an account with large UID fails login.
Product: Red Hat Enterprise Linux 6 Reporter: toasty <wrydberg>
Component: pamAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: BaseOS QE Security Team <qe-baseos-security>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 6.1CC: dapospis
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-28 08:09:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description toasty 2020-02-27 20:18:21 UTC
Description of problem:

The /var/log/tallylog file becomes very large when an account with large UID fails login.
For example:
uid=1490637575(qaetlmgr) gid=1490637559(u_qaetlmgr) groups=1490637559(u_qaetlmgr)

The file can grow larger than 50GB and its contents is getting dumped to buffer cache when reading the file using pam_tally2 with no options. This is affecting performance.
Resetting the account with large ID is not shrinking the tallylog file, so the buffer cache memory does not get released.
We need "pam_tally2 --user qaetlmgr --reset"  to remove entirely the long UID from tallylog file so the affected buffer cache can be released.

Version-Release number of selected component (if applicable):
RHEL7: pam-1.1.8-22.el7.x86_64 
RHEL6: pam-1.1.1-24.el6.x86_64
RHEL5: pam-0.99.6.2-14.el5_11

How reproducible:
Issue is reproducible when a user with large UID fails logging in and /var/log/tallylog files becomes too large.
For example if user qaetlmgr with UID 1490637575 bad login. If we run pam_tally2 with no options after the failed login then that will cause the entire tallylog file to be read and use a lot of buffer cache.  Resetting user qaetlmgr does not shrinks the tallylog file so the host still uses large buffer cache even though it was reset.  We need to remove the long UID from tallylog to relieve buffer cache usage.

Steps to Reproduce:
1. fail ssh login as qaetlmgr which has large UID 1490637575. 
2. run pam_tally2 with no options, or just cat the /var/log/tallylog file
3. reset the account:  pam_tally --user qaetlmgr --reset.  This does not free up the buffer cache since the /var/log/tallylog file is still huge.

Actual results:
The /var/log/tallylog file becomes very large when an account with large UID fails login.
For example:
uid=1490637575(qaetlmgr) gid=1490637559(u_qaetlmgr) groups=1490637559(u_qaetlmgr)

The file can grow larger than 50GB and its contents is getting dumped to buffer cache when reading the file using pam_tally2 with no options. This is affecting performance.
Resetting the account with large ID is not shrinking the tallylog file, so the buffer cache memory does not get released.
We need "pam_tally2 --user qaetlmgr --reset"  to remove entirely the long UID from tallylog file so the affected buffer cache can be released.

Expected results:
We want the file /var/log/tallylog to completely remove any entries for accounts that has been reset, so the file can become much smaller after resetting accounts that have very large UID, for example qaetlmgr with UID 1490637575

Additional info:

Comment 2 Tomas Mraz 2020-02-28 08:09:06 UTC
Yes, this is expected, by-design. The tallylog is a sparse file so the zero-ed holes will not occupy a disk space. pam_faillock does not have this property.