gtklock
gtklock copied to clipboard
account locked for no reason
This happens to me on the random basis:
Last night and 4 times tonight, out of nowhere, I had my account blocked for 10 minutes. I was playing with changing user images, using in turns mugshot and swaysettings, and also deleting images manually. No idea if it matters. I remember having a similar incident at the office, on some older gtklock version. I'm pretty sure I entered my password correctly every time, and 100% sure that I couldn't misspell it 3 times.
$ gtklock -i -m userinfo-module
** (gtklock:280886): WARNING **: 02:53:06.671: gtk-layer-shell v0.7.0 may not work on GTK v3.24.34. If you experience crashes, check https://github.com/wmww/gtk-layer-shell/blob/master/compatibility.md
(gtklock:280886): GLib-CRITICAL **: 02:53:06.703: g_key_file_load_from_file: assertion 'file != NULL' failed
(gtklock:280886): GLib-GObject-CRITICAL **: 03:03:05.260: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
Both ~/.face
and /var/lib/AccountsService/icons/piotr
are present at the moment.
I'm not sure this is a gtklock issue but it's possible that gtklock does something wrong in the PAM conversation function... Using the userinfo module shouldn't be relevant. What distro are you on? Do you have any unusual PAM configuration?
What distro are you on?
Arch Linux
Do you have any unusual PAM configuration?
Basic, probably. I had to ask Google what PAM means.
Can you check for a logged occurrence? If you check using $ journalctl --user
, there should be a message similar to:
Aug 08 17:50:41 arch gtklock[659]: pam_unix(gtklock:auth): authentication failure; logname= uid=1000 euid=1000 tty= ruser= rhost= user=lanikjo
and for $ journalctl --system
there should be something like:
Aug 08 17:49:48 arch audit[546]: USER_AUTH pid=546 uid=1000 auid=1000 ses=4 msg='op=PAM:unix_chkpwd acct="lanikjo" exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res=failed'
Aug 08 17:49:48 arch kernel: audit: type=1100 audit(1659980988.655:92): pid=546 uid=1000 auid=1000 ses=4 msg='op=PAM:unix_chkpwd acct="lanikjo" exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res=failed'
If you don't find any messages like this, maybe a different PAM service is blocking your account.
Sorry, I'm by the lake with only my old testing lappy. I'll be back in the business next week.
No problem, enjoy your vacation 😄
I am trying to get this program packaged for NixOS but seems like my passwords just don't work with the produced binary?
I am getting errors like the following
pam_warn(gtklock:auth): function=[pam_sm_authenticate] flags=0 service=[gtklock] terminal=[<unknown>] user=[dit7ya] ruser=[<unnown>] rhost=[<unknown>]
pam_warn(gtklock:setcred): function=[pam_sm_setcred] flags=0x10 service=[gtklock] terminal=[<unknown>] user=[dit7ya] ruser=[<unknown>] rhost=[<unknown>]
Any clues?
Edit: I must say I have just run the build step, and not the install step (since things are done differently in NixOS which I thought I will figure out later). Let me know if the install step is required for PAM to funcion.
Yes, the install step is required or PAM won't authenticate you. I don't know where PAM config files are located in NixOS but on other distros it's /etc/pam.d
Thanks. I figured something out and opened a PR for packaging it into NixOS.
Can you check for a logged occurrence?
For both queries I have just one occurrence dated 5th Aug. This might've been a really misspelled password.
$ journalctl --user | grep 'authentication failure'
sie 05 01:21:54 msi gtklock[92990]: pam_unix(gtklock:auth): authentication failure; logname= uid=1000 euid=1000 tty= ruser= rhost= user=piotr
$ journalctl --system | grep 'exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res=failed'
sie 05 01:21:54 msi audit[92992]: USER_AUTH pid=92992 uid=1000 auid=1000 ses=1 msg='op=PAM:unix_chkpwd acct="piotr" exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res=failed'
sie 05 01:21:54 msi kernel: audit: type=1100 audit(1659655314.176:259): pid=92992 uid=1000 auid=1000 ses=1 msg='op=PAM:unix_chkpwd acct="piotr" exe="/usr/bin/unix_chkpwd" hostname=? addr=? terminal=? res=failed'
Okay, I think I'd be best to leave the issue open for a little while or until you get another occurrence.
If you don't want gtklock to lock your account after failure I can help you configure PAM to disable the pam_faillock
module either system-wide or only for gtklock.
Well, we don't really need a solution on my machine, but anywhere. Yes, let's leave it open for further testing. I'll check journalctl if/when it happens again.
What I meant is, if it turns out to be a misspelled pw and not a gtklock issue, you could avoid it that way. If it's a bug, it should be fixed.
My /etc/security/faillock.conf
is 100% default (all lines commented out). Does gtklock need changes in it?
No, gtklock should work with default PAM and faillock configs on arch.
Anyway, has the issue reoccured at all?
No, but I only used gtklock w/o the userinfo module lately. Just added the module support in the latest nwg-shell-config, so it's going to be used on the daily basis, at least on my machines. We will see.
I've been testing for a week now, nothing bad happened. Closing. Will re-open if something goes wrong.
It happened tonight, after changing the avatar with mughshot. Dunno if it matters.
I'm still unsure, but it seems as if mistyped passwords accumulated in some way over time after startup. Maybe it's not gtklock's fault. Closing again. :rofl: