RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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: 2023-09-07 22:06 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:
Embargoed:


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.