Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#67347 - [pambase][pam] pam_faillock options

Attached to Project: Arch Linux
Opened by loqs (loqs) - Tuesday, 21 July 2020, 15:15 GMT
Last edited by David Runge (dvzrv) - Wednesday, 18 November 2020, 09:45 GMT
Task Type Bug Report
Category Packages: Testing
Status Assigned
Assigned To David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 11
Private No


Description: does not support onerr or file options.
It uses dir with default /var/run/faillock containing one file per username.
The deny option is not specified and is commented out in /etc/security/faillock.conf so I believe accounts except root will be locked after three failed attempts in 15 minutes with access re-enabled after 10 minutes. Should such a change warrant a news item?
etc/security/faillock.conf is not in the backup array of pam

Additional info:
* pambase 20200721.1-1
* pam 1.4.0-2
This task depends upon

Comment by loqs (loqs) - Tuesday, 21 July 2020, 16:39 GMT might also need:
* tmpfiles.d snippet to create /run/faillock/
* rework /etc/pam.d/system-auth so records authentication failures.

Possibly drop its use in the default pamstack?
A news item may be warranted by the removal of pam_tally, pam_tally2 and pam_cracklib which if used in a custom pamstack would cause authentication failure, potentially causing a user to be locked out of the system.
Comment by Leonard König (LeonardK) - Wednesday, 22 July 2020, 20:48 GMT
Re tally2 and such: This breaks at least pambase-homed right now. This is just an AUR package but it would be nice if this could be worked around somehow. I don't know the best way how to proceed, however. Would it make sense to make pam 1.4.0-2 on a specific version of pambase, namely 20200721.1? This would prevent issues with pam and pambase being out of sync (maybe this is even possible with a 'standard' setup if we have unlucky mirror synchronizations?) pambase-homed already provides pambase=20190105.1 thus preventing an unwanted mismatch.
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:01 GMT
Looks like pambase just needs :
1) /etc/pam.d/system-login:
auth required onerr=succeed file=/var/log/tallylog
auth required

2) sddm needs to update it's file:
auth required file=/var/log/faillog onerr=succeed
auth required

Since the security faillock policy is set in /etc/security/faillock.conf, admins can adjust for local needs there.

Comment by loqs (loqs) - Friday, 24 July 2020, 20:13 GMT
@GeneC can you produce a failed authentication to be recorded by faillock with those changes?
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:27 GMT
As per your first comment /run/faillock needs to be created (manually or otherwise). I did not make that change yet.
So, I can get it to record in system journal but nothing is written to /run/faillock/xx.
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:33 GMT
Do you know what permissions are appropriate for /run/faillock (i.e. what to put in tmpfiles.d/xx)?
man pages for pam_faillock and faillock weren't completely clear to me ... or I need more coffee.

Comment by loqs (loqs) - Friday, 24 July 2020, 20:33 GMT
That is an improvement on what I was producing which was no output.

The man page [1] documents much more invasive changes required to the pam stack.

Comment by loqs (loqs) - Friday, 24 July 2020, 20:38 GMT
Fedora creates /run/faillock with a tmpfiles.d snippet

d /run/faillock 0755 root root -

Comment by Gene (GeneC) - Friday, 24 July 2020, 20:39 GMT
Well to be clear,- what I did to test was ssh to test machine1 as tweaked the pam file as above, then watched journal.
I then ssh to a second machine2 - now on this computer, as user2 i did: % ssh user1@machine1.
That generated the failure log recorded something like: sshd[x]: pam_unix(sshd:auth): authentication failure;...

This may be different via local login.
Comment by loqs (loqs) - Friday, 24 July 2020, 20:47 GMT
I should have been clearer as well. I receive the syslog message from but I have not produced any output from
What I am suspecting is that in the current configuration is behaving the same as
Comment by Gene (GeneC) - Friday, 24 July 2020, 20:52 GMT
I tried this: manually create /run/faillock.
repeat as above - login failure recorded in journal, but now a file is created: /run/faillock/user1

it is an empty file. I was rather expecting something inside the file ... but that's what I get.
My /etc/security/faillock.conf is the default - which has only comments.

Perhaps un-comment the 'audit' item in the conf file?
Comment by loqs (loqs) - Friday, 24 July 2020, 21:14 GMT
I can generate a file /run/faillock/username if the login is authenticated.
Editing /etc/pam.d/system-login as follows as a test

auth [success=1 default=bad]
auth [default=die] authfail
auth sufficient authsucc
#auth include system-auth

authenticated logins generate an empty /run/faillock/username
failed logins generate a /run/faillock/username with a binary record
the details from the record can be read by faillock
Comment by Gene (GeneC) - Friday, 24 July 2020, 21:17 GMT
without reading more (doc/code) this is just a guess - perhaps that file is used to tag the last login time (successful or not) only - as a way to enforce the time rules for failed logins?
Comment by Gene (GeneC) - Friday, 24 July 2020, 21:47 GMT
Its pretty clear from the code[1], best I can tell anyway, it does read/write into the file and keeps a tally and details of all attempts. Calling it a day on this for now.

Comment by loqs (loqs) - Friday, 24 July 2020, 23:17 GMT
For pam patch from my first comment. Dropped cracklib depends as module is no longer built. Added the tmpfiles snippet to create /run/faillock.
For pambase using the first example in the pam_faillock man page.

Results are now more as I would expect. Still needs much more testing.
Moved up to avoid it being skipped.
Comment by loqs (loqs) - Saturday, 25 July 2020, 03:39 GMT
pambase, based on second example from pam_faillock man page.
pam, removed executable bit from tmpfiles config.
Comment by Gene (GeneC) - Sunday, 26 July 2020, 16:23 GMT
**UPdate* - this may be due to not restarting systemd etc. After rebooting to ensure all services are started fresh - below is a non issue.
Sorry for noise.

-- fixed after reboot

I'm getting additional errors in the log when user logs in
( exists and is a link to /usr/lib/ but seems to be wrong version - 1.3.2 instead of 1.4.0 )

PAM unable to dlopen(/usr/lib/security/ /usr/lib/ version `LIBPAM_MODUTIL_1.3.2' not foun
d (required by /usr/lib/security/
PAM adding faulty module: /usr/lib/security/
PAM failed: Module is unknown
user@1000.service: Failed to set up PAM session: Operation not permitted
user@1000.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted
Comment by loqs (loqs) - Tuesday, 04 August 2020, 20:07 GMT
substack and skip based approaches to adding and
Comment by loqs (loqs) - Sunday, 09 August 2020, 14:35 GMT Comment by Tobias Powalowski (tpowa) - Wednesday, 12 August 2020, 19:41 GMT
Added changes to pam-1.4.0-3 and pambase-20200721.1-2.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 12 August 2020, 20:09 GMT
@loqs Your skip implementation doesn't look sane. You're skipping over pam_systemd_home if pam_unix succeeds.
Comment by loqs (loqs) - Wednesday, 12 August 2020, 20:32 GMT
The user is managed by systemd_home or passwd. The upstream example [1] uses sufficient in auth, account and password, which would return immediately so only unix or systemd_home is required to succeed.
I did not use sufficient as that would skip entries e.g. gdm_password has after system-local-login.

Comment by Jan Alexander Steffens (heftig) - Wednesday, 12 August 2020, 20:45 GMT
Yes, thanks. I misunderstood how it works.