[SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

filotek · 2022-06-17 14:16:23

I've been looking everywhere but can't seem to find any setting that removes the Ctrl-C delay (approx. 3 seconds) when sudo prompts for a password.

I'm NOT suggesting that the delay for failed password attempts is removed. Only that if I want to abort, the terminal shouldn't be hung up for 3 seconds until I get it back. There shouldn't be any reason to assume that this *bug* (if I can call it that) is a security feature since password authentication on Ctrl-C hasn't been attempted.

To reproduce, simply type

$ sudo ls

Then Ctrl-C when the password prompt is presented.

I've tried to reproduce with Debian but can confirm that the issue is not there, so definitely working as expected. Yet I can't find the missing piece of the puzzle between my arch install and the Debian pam/sudo/login.def settings inside an LXD container.

Last edited by filotek (2022-06-20 13:40:50)

seth · 2022-06-17 20:55:53

pam_faillock, nodelay option
https://man.archlinux.org/man/faillock.conf.5.en

debian probably still uses pam_tally

I'm not sure how to exempt SIGINT, though.

loqs · 2022-06-17 21:19:10

#%PAM-1.0

auth       required                    pam_faillock.so      preauth
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth      [success=2 default=ignore]  pam_systemd_home.so
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail nodelay fail_interval=0
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

seth I thought that too but with the above the delay is still present

seth · 2022-06-17 21:27:43

#%PAM-1.0

auth       required                    pam_faillock.so      preauth nodelay # this line, too
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth      [success=2 default=ignore]  pam_systemd_home.so
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail nodelay fail_interval=0
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

loqs · 2022-06-17 21:36:31

#%PAM-1.0

auth       required                    pam_unix.so nodelay
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc

Still produces a delay on ctrl+c

seth · 2022-06-17 21:46:00

You added nodelay to pam_unix instead of/but not pam_faillock
Add nodelay to all pam_faillock lines in system-auth and try again

loqs · 2022-06-17 21:50:28

Thanks this got it

#%PAM-1.0

auth       required                    pam_faillock.so      preauth nodelay
# Optionally use requisite above if you do not want to prompt for the password
# on locked accounts.
-auth      [success=2 default=ignore]  pam_systemd_home.so
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail nodelay
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc nodelay
# If you drop the above call to pam_faillock.so the lock will be done also
# on non-consecutive authentication failures.

seth · 2022-06-17 21:59:43

And the last one

auth       required                    pam_faillock.so      authsucc nodelay

should™ not be necessary.

The problem remains that idk how to treat SIGINT different from a fail (except by patching sudo, I guess) or what implications that would have (since techincally one failed the authentiation)

filotek · 2022-06-20 13:40:27

I erroneously thought I would receive an email for replies as the author of this thread; didn't realize I still needed to subscribe to the thread. Apologies for the delay!

Thanks very much @seth! Like @loqs, I was able to resolve this by introducing the nodelay keyword as you suggested in the /etc/security/faillock.conf file instead of modifying /etc/pam.d/system-auth.

With this modification, the delay only happens on SIGINT (Ctrl-c) and not on password failures. For password failures, it still waits the requisite 3 seconds. I don't know why SIGINT is treated differently or why the `nodelay` is not honored for authentication failures. I can only presume that the faillock.conf file acts like a default, over-ridden only by those changes found defined in `/etc/pam.d/system-auth`. This seems to be the inverse of what @seth was experiencing?

I'll mark the thread as solved as it appears to work for me (it only short-circuits the wait for SIGINT, but preserves wait-time for failed attempts). But I caution any future on-lookers to verify that the 3 second delay is still honored for *failed* password attempts by sudo, screenlocks, etc.

filotek · 2022-06-20 13:53:24

I decided to undo my changes to /etc/security/faillock.conf and apply the `nodelay` option to my pam configuration files instead, to see if I could get the inverse effect of what @seth had described. But oddly enough, I get the exact SAME behaviour!

It short-circuits the SIGINT, but still maintains the 3 second delay for failed password attempts. It makes me worried that `nodelay` isn't being honored properly and that some future fix might end up doing me harm instead, by removing the timeout for failed attempts (wrong password) instead of abandoned attempts (SIGINT).

seth · 2022-06-20 14:01:03

The remaining delay is because the wrong password has you fail in pam_unix, which itself delays the process.
You can issue it "nodelay" likewise and be rid of any delay on fatfingering your creds ;-)

filotek · 2022-06-20 14:17:35

Ahhh... ok! Thanks again! Confidence restored! I want delays for failed attempts (fat-fingered or otherwise), just no delays for abandoned attempts! But I think you knew that already :-)

Again, for a future audience that wants to know more... this thread prompted me with additional keywords I could use to search on surrounding delays and I also found this thread very informative.

https://bbs.archlinux.org/viewtopic.php?id=262258

Arch Linux

#1 2022-06-17 14:16:23

[SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#2 2022-06-17 20:55:53

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#3 2022-06-17 21:19:10

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#4 2022-06-17 21:27:43

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#5 2022-06-17 21:36:31

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#6 2022-06-17 21:46:00

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#7 2022-06-17 21:50:28

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#8 2022-06-17 21:59:43

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#9 2022-06-20 13:40:27

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#10 2022-06-20 13:53:24

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#11 2022-06-20 14:01:03

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

#12 2022-06-20 14:17:35

Re: [SOLVED] Remove Ctrl-C delay (3s) when Sudo prompts for password.

Board footer