Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

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!
Tasklist

FS#67644 - [pam][pambase] Locked out after one wrong password attempt

Attached to Project: Arch Linux
Opened by Robert Balent (RobertBalent) - Thursday, 20 August 2020, 07:24 GMT
Last edited by David Runge (dvzrv) - Wednesday, 18 November 2020, 09:46 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Tobias Powalowski (tpowa)
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 25
Private No

Details

Description:

After latest pam update I'm being locked out of the account after only one wrong password attempt. It shows that I reached limit of 3 wrong password attempts and that I should wait 10 minutes.

I didn't modified any configuration and I never enabled account lock after wrong passwords.

This seems to be related to fprint package. I have fprintd daemon disabled and don't have any fingerprints configured. But it seems like it's started anyway? After uninstalling it, I'm being locked out of the account after 3 wrong password attempts.

So there are 2 issues:

1. Why is this behavior enabled at all? I never enabled it.
2. Why I'm locked out after 1 wrong password attempt when fprint is installed?


Environment:

I'm using Gnome and default Gnome login screen.


Package versions:

pam 1.4.0-3
pambase 20200721.1-2
fprintd-1.90.1-1
libfprint-1.90.2-1
gdm 3.36.3-6
systemd 246.2-1


Log file attached.
This task depends upon

Comment by Trit' (trit) - Thursday, 20 August 2020, 15:09 GMT
Same for me: I just locked my XFCE session once, today, and XScreenSaver would not let me type my password, and trying to log in in a TTY console did not work either. I had to log in as root (for the very first time since I have installed Arch on this PC, in July 2016!) and reboot the PC to be able to open my XFCE session again. Luckily, I did not have opened files at this time, so no unsaved data was lost. But for people who had such unsaved important files… :/

I’d say that, when being on a personal PC and not a professional server, there is no need to set a limit to how many wrong attempts can be done before locking completely a user session. It’s the first time I have been locked out of my own PC, and I am not very happy about it.

EDIT: fprint is not installed on my system. I only have pam and pambase, which I have both updated today.

EDIT 2: last pam update added a new file: etc/security/faillock.conf. The 3 wrong attemps limits is stored there (3 is the default, even if the matching line is commented out), but I don’t know how to set it to “no limit at all”.
Comment by Trit' (trit) - Saturday, 22 August 2020, 08:55 GMT
Regarding to https://bbs.archlinux.org/viewtopic.php?id=258335 (wait, I sincerely think that that bug is related to this one): I have another PC that I just upgraded some minutes ago, ignoring pam and pambase updates. And you know what? VLC, Notepadqq (as samples of Qt5 softwares) run with the good Qt5 theme as defined by qt5ct. Therefore, I think that this pam update is also responsible for the bug in Qt5 applications (it’s really the only difference between my laptop, where pam was updated, and the desktop, where it wasn’t).

Please let that know in the forum, because I am not able to sign in there (the last question fails continuously, despite I am giving the awaited answer).
Comment by Rowisi (Rowisi) - Monday, 24 August 2020, 23:26 GMT
Not only login locked after 3 wrong attempts but also sudo is locked after 3 wrong attempts.

Not sure who and why did they do such a terrible change? Did they ask Linux users before doing such change?
Comment by nl6720 (nl6720) - Tuesday, 25 August 2020, 06:30 GMT
You can set 'deny = 0' in /etc/security/faillock.conf to disable the lockout feature.
Comment by patrick (potomac) - Tuesday, 25 August 2020, 09:10 GMT
I agree with Rowisi, this is a terrible change, "deny = 0" should be the default setting, in order to avoid these problems,

it would be interesting to see if other linux distros (ubuntu, fedora) will follow or not this default setting when they will switch to pam 1.4.0.
Comment by Trit' (trit) - Tuesday, 25 August 2020, 09:35 GMT
“deny = 0” fixed both the lockout and the appearance of the Qt5 applications for me! Thank you a million times, nl6720!!! \o/

PS: could you report this to the forum again, Robert? Because despite of what V1del thinks, there clearly was a link between pam’s bug and (my, at least) Qt5 bug. And set this “deny” parameter to 0 in /etc/security/faillock.conf fixed everything. It could be good to know, don’t you think? Thank you.
Comment by Jiri Valnoha (waldauf) - Tuesday, 25 August 2020, 13:13 GMT
I have the same problem. Solution 'deny = 0' helped me. But in case I would like to have a locked system for some time after X failed logins so it will not work. I think this is an error that should be fixed.
Comment by Jonathan Kotta (jpkotta) - Friday, 28 August 2020, 17:39 GMT
@Jiri Valnoha (waldauf) you can just set `deny = X` for whatever number X of failed attempts you want. Default is 3. 0 is special, meaning infinity. I think 3 is an aggressive default, and probably too low, but it's not really an error because it's working as intended.
Comment by Lukas Sabota (punkrockguy318) - Friday, 28 August 2020, 19:37 GMT
I think a change in behavior like this warrants some type of notification. This is a pretty disruptive change for people that often mistype their password. "deny = 3" in faillock.conf is a questionable upstream pam default - and if Arch is going to stick with the upstream behavior, I think that the new behavior should be communicated in a package postinstall message or the arch home page.

It's just very confusing for this to happen without notice.

edit: rephrased
Comment by Trit' (trit) - Saturday, 29 August 2020, 11:56 GMT
It’s me, again…

So, I updated pam and pambase on my other Arch PC, I have edited “/etc/security/faillock.conf” to set “deny = 0”, and… I did not work, this time. XScreenSaver showed me a big “Authentication failed!” after I have tested if everything was OK (it wasn’t). After a reboot, VLC (Qt5 app) is not using the good theme (Fusion, the default Qt5 theme, instead of gtk2, as defined in the “QT_QPA_PLATFORMTHEME=qt5ct” variable in “/etc/environment”), except if I run it from a Terminal.

Both PC configurations are the same, pam-related files are identical on both machines, so I don’t know what to do to fix that…
Comment by Henry Nelson (hcnelson99) - Saturday, 29 August 2020, 15:42 GMT
As a further workaround before the default is set to deny = 0, you can unlock an account with "faillock --user $USER --reset"
Comment by Peter Ross (peterross) - Friday, 11 September 2020, 08:29 GMT
I had the same problem, of being completely locked out after the update and got back in to investigate by using the Arch install media. I tracked the problem down to the fact that the update had removed the PAM tally2 module, now that faillock does that work. My config had used tally2 in /etc/pam.d/system-login to count login fails and enforce a login delay after three failures. I commented out those lines where they occurred; problem cured, for me, without changing the defaults in faillock.conf
Comment by Levente Polyak (anthraxx) - Friday, 11 September 2020, 11:11 GMT
locking after 3 wrong attempts is a quite sane upstream default that i don't see why it should diverge downstream. If people are not happy because they mistype frequently then just configure it. This is not post install message material, it simply belongs to the Arch Wiki and that is fully open for contribution.
Comment by Rowisi (Rowisi) - Friday, 11 September 2020, 13:49 GMT
@anthraxx It would be okay if it was 10 by default but 3 is just too low. The default settings must always be for general users who probably don't mess with /etc. At work or at universities we mistype passwords very frequently and its very common to type the wrong password for computers that are not ours. Linux is no longer for developers only, It has became a general OS for all kind of people to use and 99% of people will not be happy about this.
Comment by Doug Newgard (Scimmia) - Friday, 11 September 2020, 14:03 GMT
Rowisi, I think you're forgetting what distro we're talking about. "general users who probably don't mess with /etc" are not Arch users.
Comment by Rowisi (Rowisi) - Friday, 11 September 2020, 14:08 GMT
@Scimmia Manjaro users aren't Arch users too? Won't this affect them?

So, if Debian does some breaking changes, won't that affect Debian based distros too?
Comment by Doug Newgard (Scimmia) - Friday, 11 September 2020, 14:13 GMT
No, Manjaro users are NOT Arch users, nobody here cares one bit how it affects Manjaro users.
Comment by Rowisi (Rowisi) - Friday, 11 September 2020, 14:25 GMT
@Scimmia These changes aren't Arch fault either. Linux-pam are doing it, lets just hope they won't change it to 1.
Comment by David C. Rankin (drankinatty) - Saturday, 12 September 2020, 03:01 GMT
The problem is:

# The default is 900 (15 minutes).
# fail_interval = 900

So any 3 wrong passwords in a 15 minute period of time will lock the box according to the faillock.conf. So if you accidentally type a wrong password on login. Type a wrong password with sudo 10 minutes later. and then 4 minutes after than type a wrong password with sudo again -- you are locked -- even though you never had 3 failed passwords at any one prompt. This may be a bit too rigorous for home user use.

It looks like if you are a member of some group, you can stop it from locking by treating that group the same as root with:

# admin_group = <admin_group_name>

The 3 in 15 minutes by default will catch a lot of people. There should be a way to limit it to 3 in 15 minutes at a single prompt. That would be much better than any 3 fails in 15 minutes.
Comment by Allen (allencch) - Saturday, 12 September 2020, 05:21 GMT
The problem I faced was when xscreensaver was activated, but I didn't enter the password for some time. Then the account is locked for 15 minutes. Only after 15 minutes, I can only unlock the xscreensaver.
Comment by Rowisi (Rowisi) - Saturday, 12 September 2020, 06:57 GMT
Even though it is so easy to change the configuration, I try as much as possible to not mess with /etc files and stick to default configurations and the reason is that if breaking changes happen I don't want it to save as s *.pacnew file and then I will have to use a live usb and mount partition to fix it.
Comment by John (graysky) - Saturday, 12 September 2020, 12:29 GMT
@Allen - Same. Switching to xfce4-screensaver here solved that issue for me. Only applicable if you're running xfce4 obviously.
Comment by Olav Seyfarth (nursoda) - Saturday, 12 September 2020, 22:23 GMT
There are TWO issues: [1] defaults (personally I agree that 3 in 15' is hard, should be reset on success) and [2] something's triggering this despite of NOT 3 false attempts. Let's focus on that, please: Today, I pressed the power button on my laptop, sending it to sleep. After a while, I pressed power button again to wake it, and ended up with a SDDM login screen WITHOUT password entry field or any possibility to do anything (on that graphical terminal). Background image was there, but the usual password field was missing. So I switched to another text terminal, found out about the lockout (I had not, if I hadn't changed to text console), and killed the screenlocker (since I didn't know "faillock --reset", thanks hcnelson99). As a workaround I set deny=0, but what caused it in the first place and why did this not hit us before?
Comment by loqs (loqs) - Saturday, 12 September 2020, 22:59 GMT
@nursoda pam_tally / pam_tally2 recorded failures but the default configuration did not take any other action.
There were also limitations in when pam_tally2 could record failures, the tallylog was only acessible by root so none root authenticating services such as screenlockers would error attempting to access the file and failures would never be recorded.
It could also be an issue in the pambase changes or an issue in the pam_faillock module itself.
Comment by Olav Seyfarth (nursoda) - Sunday, 13 September 2020, 00:41 GMT
Understood, and appreciated. For the record: In my case, pam_tally2 is not even installed. So, as this hits users (not only admins), who is able to investigate the cause and what evidence is needed to do so? Personally, I never really got into the whole pam mechanism, and I'm not trying to. All I wanted to do here is to refocus that this [A] should not happen (yes, we may blame the upstream update) and [B] that this does NOT ("only") happen when entering a wrong password three times in a row. So, discussion about 3 or 10 Minutes default is out of scope for this bug.
Comment by loqs (loqs) - Sunday, 13 September 2020, 02:01 GMT
pam_tally and pam_tally2 were deprecated in the pam 1.4 release and not built by default. The suggested replacement in the upstream release notes [1] is pam_faillock.
pam_faillock is not a drop in replacement for pam_tally / pam_tally2. pam_tally / pam_tally2 used a single call [2] while pam_faillock takes at least two [3]
this was one of the reasons for the pambase 20200721.1-2 changes that accompanied the pam 1.4.0-3 update.

Has anyone experienced the issue when there has been no GUI active or at least no GUI with a login or authentication prompt?

[1] https://github.com/linux-pam/linux-pam/releases/tag/v1.4.0
[2] https://man7.org/linux/man-pages/man8/pam_tally2.8.html
[3] https://linux.die.net/man/8/pam_faillock
Comment by Tobias Mädel (Manawyrm) - Wednesday, 16 September 2020, 18:19 GMT
This is an absolutely insane default. It is not acceptable at all as the default configuration, even less so as a regular system update.

HID events are also triggered by other devices like wireless headphones (in my case), which often emit spurious events/keypresses.
In my case, xscreensaver was activated multiple times by the HID input from the headphones and caused a 10 minute lockdown of my machine, which I had to fix with a reboot from a VTY.
This caused a small amount of lost data because the computer was logging measurements while I was away.
Comment by David Rosenstrauch (darose) - Thursday, 17 September 2020, 13:59 GMT
@Manawyrm I was experiencing that as well. I would close the lid on my machine, then come back to it a few hours later, only to find that I was locked out for the next 10 minutes. I wound up setting 'deny = 0' in /etc/security/faillock.conf to disable this.
Comment by Chris Billington (chrisjbillington) - Sunday, 20 September 2020, 07:23 GMT
I've locked myself out a bunch of times and don't really know why. It's definitely not from actually entering my password wrong.

I have also wondered if it might have something to do with suspending my laptop whilst sudo is prompting for a password. Or perhaps whilst yay is running with the sudoloop option, and is waiting for (non-password) input. Haven't figured it out, but will be setting deny=0 until such a time this no longer occurs with defaults.
Comment by rainer (raneon) - Wednesday, 07 October 2020, 15:47 GMT
I've been locked out of my systems now multiple times too and I'm not sure why. Almost out of nothing my password is not accepted anymore.

On my laptop it happened after suspend and I'm pretty sure I didn't type the password 3 times wrong withing 15 minutes.

On my servers I see this issues too, and I believe it is somehow related to the cockpit ssh bridge. But it doesn't make sense as my user password is accepted during the login to the cockpit dashboard and would be correctly forwarded to the other cockpit machines.
Comment by M (mjr) - Sunday, 25 October 2020, 01:04 GMT
This just affected me. Got locked out with some work open. Thankfully I forgot to disable the root account on this newish install so I could get back in and set "deny = 0" without waiting or losing work.

This seems like a pretty bad default.
Comment by rainer (raneon) - Sunday, 25 October 2020, 10:10 GMT
This is still affecting my systems. I'm getting constantly locked out when using cockpit on my servers. Can we please get a fix or at least a proper advise how to fix this?
Comment by Kerrick Staley (KerrickStaley) - Thursday, 29 October 2020, 04:44 GMT
rainer: Based on previous comments, the fix is to set "deny = 0" in /etc/security/faillock.conf and raise the issue with PAM upstream if you think the default behavior does not make sense. PAM's page is at http://www.linux-pam.org/. It looks like they have a mailing list that you can register for at https://listman.redhat.com/mailman/listinfo/pam-list .
Comment by rainer (raneon) - Friday, 30 October 2020, 23:24 GMT
Kerrik: I'm aware about this workaround, thanks. I would like to know how Arch Linux as a distribution will address this. I'm not in a position to tell the pam developers how to do their job as I'm just a normal user that is affected by this issue without knowing any details.
Comment by webdawg (webdawg) - Wednesday, 11 November 2020, 22:52 GMT
rainer: https://principles.design/examples/the-arch-way

Archlinux is the exact opposite of what you are talking about.

Though, why wasn't a change like this posted in the news? I was surprised also. I guess I could see why....
Comment by rainer (raneon) - Wednesday, 11 November 2020, 23:21 GMT
webdawq: As a long time Arch Linux user I'm fine with doing setups during installation or when changes are necessary so that my systems fit my needs. But this is about a changed behavior where a normal upgrade broke several functionalities. Hence I did request that there is some communication. Not every user is always aware about all the details and has the time to figure it out for himself. Especially if the bug cannot be linked directly to one package as it is not obvious. So I still have the expectation that if something breaks we communicate openly and that there is then some form of communication (news/wiki, ...).

So let me quote the link you've posted:
"It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems. All users are encouraged to participate and contribute to the distribution. Reporting and helping fix bugs is highly valued and patches improving packages or the core projects are very appreciated"
Comment by Trit' (trit) - Wednesday, 18 November 2020, 10:08 GMT
The new version 1.5 has finally fixed my problem with Qt5 applications not having the good theme in XFCE on one of my PCs (cf. https://bugs.archlinux.org/task/67644#comment192194). It was a bug in pam_env’s code.

Loading...