terminal login interrupt support (eg. SIGINT/ctrl+c)?

cdelorme · 2020-12-07 04:50:19

I use a terminal login, as in no desktop manager, display manager, or GUI tools.

Basically, `base` and `base-devel` at install.

With at least two other distributions of linux (Debian and Fedora) I noticed I can use ctrl+c to interrupt a login when I fat finger my credentials.

This would immediately clear and display a fresh login option.

However, on arch, if I typo my username, I have to sit and wait for a few seconds before it bounces back with the failure, and ctrl+c is ignored entirely.

I am curious if it is possible to add support for this behavior, and if so how?

Cheers,

seth · 2020-12-07 08:06:34

https://packages.debian.org/search?suit … ords=getty
Doesn't suggest that at least debian was using agetty - which getty do they invoke? Did you check whether there's an arch package (in dout AUR) for it?

cdelorme · 2020-12-07 14:06:26

I installed arch and no-longer have a debian box to work with.

According to their documentation debian uses `agetty` from the `util-linux` package:
https://wiki.debian.org/getty

This appears to be the same as arch, although debian does not document their launch command:
https://wiki.archlinux.org/index.php/getty

I can confirm that agetty is being used on my system:

 systemctl status | grep getty
           │     └─1923997 grep --color=auto getty
             ├─system-getty.slice 
             │ └─getty@tty2.service 
             │   └─1754784 /sbin/agetty -o -p -- \u --noclear tty2 linux

I don't find any results when I use `pacman -Ss getty`, and the AUR has `fbgetty` `mingetty`, `mgetty`, and some others, but no _alternative_ `agetty`.

I'm diving deeper into the util-linux source now, and will post a follow-up, but if anyone knows whether I'm missing some option for agetty, or can confirm that the versions of agetty are modified between debian and arch that would be useful to know.

cdelorme · 2020-12-07 14:27:30

If I follow the arch linux documentation to the util-linux source I find:
https://github.com/karelzak/util-linux

While I can find mention of SIGINT in the agetty source, I can't make heads or tails of what it is actually doing before or after:
https://github.com/karelzak/util-linux/ … tty.c#L390

When I search for the debian util-linux package I eventually made my way to this source:
https://salsa.debian.org/debian/util-linux

The same lines appear to be present in this file:
https://salsa.debian.org/debian/util-li … tty.c#L390

In fact, comparing the contents of the agetty source at both locations reveals that they are identical.

I'm going to try and find the systemd unit file that debian uses next to see if the options differ, but if anyone can suggest other possibilities besides command options that could make an interrupt work on one system but not the other then let me know.

cdelorme · 2020-12-07 14:39:58

So I found the unit file used by debian here:
https://salsa.debian.org/systemd-team/s … ice.m4#L41

Comparing the debian template there are only two items that are different:

m4_ifdef(`HAVE_SYSV_COMPAT',
After=rc-local.service
)m4_dnl

m4_ifdef(`ENABLE_LOGIND',,
KillMode=process
)m4_dnl

Other than these two conditional lines, everything else was identical to my arch unit file.

This means no extra options are passed, so I'm back to asking if there are any other possibilities here?

Trilby · 2020-12-07 14:45:56

cdelorme wrote:

While I can find mention of SIGINT in the agetty source, I can't make heads or tails of what it is actually doing before or after:
https://github.com/karelzak/util-linux/ … tty.c#L390

That assigns SIGINT to be handled by the SIG_IGN handler which - as the name implies - completely ignores the signal. So that code will not respond to a Ctrl-C on any distribution.

The default SIGINT behavior is restored only after the prompts have been responded to.

Last edited by Trilby (2020-12-07 14:46:38)

seth · 2020-12-07 14:49:50

If the gettty is equivalent, the input is probably handled differently by the login process itself.
Though https://salsa.debian.org/debian/util-li … in.c#L1238 actually ignores sigint immediately…

If we ignore the SIGINT and you "grep pam_unix /etc/pam.d/*" - is there "nullok" or "nodelay" on debian?

cdelorme · 2020-12-07 15:23:12

Thank you both for clarifying the C behavior, I wasn't sure if it was being ignored or attaching some function by reference defined in another file.

I just installed debian on a spare junker laptop to check things more directly.

Here is what I found for `nullok`:

grep -r "nullok" /etc/pam.d/
/etc/pam.d/common-auth:auth [success=1 default=ignore] pam_unix.so nullok_secure

There is a comment about `nodelay` in /etc/pam.d/login, but no actual usage of it.

On my arch system, I also have `nullok` but not with `_secure` which might be a debian specific thing?:

 grep -r "nullok" /etc/pam.d/
/etc/pam.d/system-auth:auth       [success=2 default=ignore]  pam_unix.so          try_first_pass nullok
/etc/pam.d/system-auth:password   required                    pam_unix.so          try_first_pass nullok shadow
/etc/pam.d/passwd:password	required	pam_unix.so sha512 shadow nullok

I'm going to record a video and throw it up on youtube shortly to demonstrate the login behavior I am referring to.

cdelorme · 2020-12-07 15:59:42

In case there are any questions about what I am trying to do, here is a video with a side-by-side comparison of arch and debian login behavior.
https://youtu.be/qb1LIMD7EWU

My goal is to be able to ctrl+c to cancel a login with known errors instead of being required to continue until failure.

Assuming that is possible, I need help tracking down what needs to be changed.

seth · 2020-12-07 16:34:21

Can you (on debian) ctrl+c before you enter the password (ie. write "root", DON'T hit enter, but ctrl+c)?
I could imagine the init daemon handling this, but fedora *very* most likely uses systemd as well…

cdelorme · 2020-12-07 17:44:50

Good question, I did test it but wasn't sure it was important.

I am unable to use ctrl+c until I enter some value for the username and hit the enter key.

So ctrl+c won't reset until the password prompt is there.

seth · 2020-12-07 21:20:23

So it only works for the login process.
On the debian system, enter the username (so you get the password prompt) and on a different terminal check the process list for the login process (binary and parameters - eg. ps aux | grep tty1)

cdelorme · 2020-12-07 22:10:50

On both systems I logged into tty2 and ran `watch ps a`, then began the process on tty1.

On both debian and arch the PID for /sbin/agetty became `/bin/login -p --`.

I am not sure what `/bin/login` actually is, or if it differs between them.

Trilby · 2020-12-07 22:31:22

login is what you actually enter the username and password into, so that is going to be more relevant than agetty which primarily just sets up the tty. What login implementation is used on debian, which package provides it~~, and what flags/options are used for it~~? (edit: the last part was in your previous post, so nvm that).

Last edited by Trilby (2020-12-07 22:32:15)

seth · 2020-12-08 08:54:51

Might very well be the shadow implementation:
https://packages.debian.org/buster/login
https://sources.debian.org/src/shadow/1 … c/login.c/

It's removed in favor of util-linux with arch, https://github.com/archlinux/svntogit-p … BUILD#L104

schard · 2020-12-08 10:01:22

Maybe an alternative solution is to just not use [Ctrl]+[C], but [Ctrl]+[ U] to clear the current line to the beginning.
I.e.

Login: myuser
Password: fuckeduppassword<[Ctrl]+[ U]>actualpassword<Enter>

Will successfully log you in.

In case you already screwed up your user name:

Login: wrongusername
Password: <[Ctrl]+[D]>

will make the login fail instantly.

Last edited by schard (2020-12-08 10:05:59)

seth · 2020-12-08 14:17:07

His problem is the 2nd case, but ctrl+d should™ still trigger the password delay, yesno?

schard · 2020-12-08 14:25:51

Indeed it does. It was merely a suggestion to not hit enter on a wrong user name or password, but instead use the mentioned shortcuts to correct the input.
If I occasionally hit enter on a misspelled user name and have to abort login, I accept that I now wasted two seconds of my life, which I usually use to contemplate why I never took a typewriting course.

Last edited by schard (2020-12-08 14:26:13)

Arch Linux

#1 2020-12-07 04:50:19

terminal login interrupt support (eg. SIGINT/ctrl+c)?

#2 2020-12-07 08:06:34

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#3 2020-12-07 14:06:26

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#4 2020-12-07 14:27:30

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#5 2020-12-07 14:39:58

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#6 2020-12-07 14:45:56

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#7 2020-12-07 14:49:50

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#8 2020-12-07 15:23:12

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#9 2020-12-07 15:59:42

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#10 2020-12-07 16:34:21

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#11 2020-12-07 17:44:50

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#12 2020-12-07 21:20:23

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#13 2020-12-07 22:10:50

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#14 2020-12-07 22:31:22

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#15 2020-12-08 08:54:51

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#16 2020-12-08 10:01:22

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#17 2020-12-08 14:17:07

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

#18 2020-12-08 14:25:51

Re: terminal login interrupt support (eg. SIGINT/ctrl+c)?

Board footer