Bug 2062512

Summary:	Failure record file under /var/run/faillock removed after os reboot
Product:	Red Hat Enterprise Linux 8	Reporter:	masanari iida <masanari.iida>
Component:	pam	Assignee:	Iker Pedrosa <ipedrosa>
Status:	CLOSED ERRATA	QA Contact:	Anuj Borah <aborah>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	8.3	CC:	aborah, chorn, ddas, pbrezina
Target Milestone:	rc	Keywords:	Triaged
Target Release:	---	Flags:	pm-rhel: mirror+
Hardware:	All
OS:	Linux
Whiteboard:	review
Fixed In Version:	pam-1.3.1-25.el8	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	2126632 (view as bug list)		Environment:
Last Closed:	2023-05-16 09:02:48 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:
Bug Depends On:
Bug Blocks:	2126632

Description masanari iida 2022-03-10 02:31:37 UTC

Description of problem:
Followint test is done on a system which enabled faillock feature.

If admin reboot a system after one of the user's account locked by faillock,
the user's failure record in /var/run/faillock will be removed and the user's
account will become unlocked status.

I am not saying this is a bug.
If developer think this is an expected result, please add the information 
in pam_faillock man page or README in /usr/share/doc.

Version-Release number of selected component (if applicable):
pam-1.3.1-11.el8.x86_64

How reproducible:
Always

Steps to Reproduce:
1.  Enable faillock feature
  # authselect enable-feature with-faillock

2. Attempt to login to the system with wrong password at least 3 times.

3. make sure the failure is recorded in /var/run/faillock/user_name file
  # faillock --user user_name

4. reboot the system

5. Try to login to the system with the test user with correct password.

Actual results:
The user can login to the system. 

Expected results:
The user can not login to the system, 
because the user's account already account locked before reboot.

Additional info:

Comment 1 Iker Pedrosa 2022-03-10 08:25:41 UTC

/var/run is symlinked to /run, which is a tmpfs that exists only in memory. Thus, when the system reboots the content of the folder is recreated and all the information is lost.

As a possible workaround you can edit the content of /etc/security/faillock.conf to point to another directory instead of /var/run/faillock.

Comment 2 masanari iida 2022-03-10 11:43:31 UTC

Thanks for the reply.
I understand why the failure record files are removed after reboot.
As I wrote in description, I would like to see an information that
failure record files are removed after reboot.

If this information doesn't fit in man page,
then I would like to discuss with Christian Horn about possibility
to create a KB about this.

In the mean time, I know that Red Hat is working on bz#1978029.
If I want add a workaround (save failure information files on 
storage, instead of tmpfs) in the KB, then I need to write about
current faillock limitation. 

Probably, I need to think about impact of SELinux, 
if I want to save the failure record files other than /var.

Comment 3 Christian Horn 2022-03-11 00:42:03 UTC

kbase is possible, but having it in the man-pages would mean it
also gets to upstream and other distros, so might be preferable.

Comment 4 Iker Pedrosa 2022-03-11 08:37:27 UTC

I'll include that in the man pages so that everybody is aware of the possible problem.

Comment 5 masanari iida 2022-03-11 08:41:11 UTC

Thank you for your decision. 
Every body will be happy.
Masanari

Comment 8 Iker Pedrosa 2022-11-09 08:14:38 UTC

master:
    pam_faillock: Clarify missing user faillock files after reboot - bcbf145ce925934214e48200c27c9ff736452549

Comment 13 errata-xmlrpc 2023-05-16 09:02:48 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (pam bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:2954