gtklock icon indicating copy to clipboard operation
gtklock copied to clipboard

account locked for no reason

Open nwg-piotr opened this issue 2 years ago • 13 comments

This happens to me on the random basis:

image

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.

nwg-piotr avatar Aug 04 '22 23:08 nwg-piotr

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?

jovanlanik avatar Aug 07 '22 13:08 jovanlanik

What distro are you on?

Arch Linux

Do you have any unusual PAM configuration?

Basic, probably. I had to ask Google what PAM means.

nwg-piotr avatar Aug 08 '22 12:08 nwg-piotr

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.

jovanlanik avatar Aug 08 '22 17:08 jovanlanik

Sorry, I'm by the lake with only my old testing lappy. I'll be back in the business next week.

nwg-piotr avatar Aug 08 '22 19:08 nwg-piotr

No problem, enjoy your vacation 😄

jovanlanik avatar Aug 08 '22 22:08 jovanlanik

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.

dit7ya avatar Aug 10 '22 17:08 dit7ya

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

jovanlanik avatar Aug 10 '22 21:08 jovanlanik

Thanks. I figured something out and opened a PR for packaging it into NixOS.

dit7ya avatar Aug 11 '22 06:08 dit7ya

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'

nwg-piotr avatar Aug 15 '22 12:08 nwg-piotr

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.

jovanlanik avatar Aug 16 '22 12:08 jovanlanik

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.

nwg-piotr avatar Aug 16 '22 22:08 nwg-piotr

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.

jovanlanik avatar Aug 17 '22 13:08 jovanlanik

My /etc/security/faillock.conf is 100% default (all lines commented out). Does gtklock need changes in it?

nwg-piotr avatar Aug 17 '22 23:08 nwg-piotr

No, gtklock should work with default PAM and faillock configs on arch.

Anyway, has the issue reoccured at all?

jovanlanik avatar Aug 29 '22 15:08 jovanlanik

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.

nwg-piotr avatar Aug 29 '22 22:08 nwg-piotr

I've been testing for a week now, nothing bad happened. Closing. Will re-open if something goes wrong.

nwg-piotr avatar Sep 05 '22 22:09 nwg-piotr

It happened tonight, after changing the avatar with mughshot. Dunno if it matters.

image

journalctl-user

journalctl-system

nwg-piotr avatar Sep 16 '22 01:09 nwg-piotr

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:

nwg-piotr avatar Sep 29 '22 22:09 nwg-piotr