Bug 1808112 - The /var/log/tallylog file becomes very large when an account with large UID fails login.
Summary: The /var/log/tallylog file becomes very large when an account with large UID ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: pam
Version: 6.1
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-27 20:18 UTC by toasty
Modified: 2020-02-28 08:09 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-28 08:09:06 UTC
Target Upstream Version:


Attachments (Terms of Use)

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.


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