8 ms·

Chasing missing SIGINT signals down the SSH rabbit hole

80 points by craigkerstiens 8y ago

russjones 8y ago
Author here, happy to answer any questions about the post.
- yayana 8y ago
  Is the double meaning of the headline intentional? I was expecting a timing or other attack to determine data has a particular origin..
  - wyldfire 8y ago
    No it's [probably] not. SIGINT is unfortunately ambiguous, unlike SIGKILL, SIGTERM, SIGQUIT, SIGUSR1. :)
    - derefr 8y ago
      I'd have suggested "missing Ctrl+C" instead (like the title of the bug report.)
      - c12 8y ago
        As far as I know SIGINT is the name of the signal and Ctrl+C is simply a key combination that triggers it. I read the title to mean SIGINT the signal and it wasn't until I came to HN comments did I see have another meaning.
    - deleted 8y ago
      [deleted]
  - russjones 8y ago
    Ha, nope, didn't realize this until everyone started mentioning it in the comments.
godelmachine 8y ago
I took SIGINT for Signal Intelligence
- erric 8y ago
  You're not the only one
- dboreham 8y ago
  Me too, since I date back to before signals had symbolic names.
- bcaa7f3a8bbc 8y ago
  Since 2013, I always have to double-check whether the context is Unix programming or mass surveillance when I encounter this term...
Drdrdrq 8y ago
I created an ssh terminal over browser back in the day (kind of like ajaxterm, but proprietary). I tried at least 4 different libraries over the years, but there would always be that one special device that refused to play ball. In the end I used an OpenSSH process, connected to it and drove it through input/output. Made those customer support calls really short: "Did you try connecting from the command line?"
kccqzy 8y ago
I've gradually learned to almost always allocate a PTY, whether it be ssh or some docker run. Too many programs work badly or unexpectedly differently when fd 0 or 1 is not a terminal. Maybe we should start collecting a hall of shame for programs that insist on dealing with a terminal, not just a pipe. Another fun fact I just came across a few weeks ago. The sudo command doesn't always handle job control signals in the way you expect it to. From its manual: > There are two distinct ways sudo can run a command. If an I/O logging plugin is configured or if the security policy explicitly requests it, a new pseudo-terminal (“pty”) is allocated and fork(2) is used to create a second sudo process, referred to as the monitor. The monitor creates a new terminal session with itself as the leader and the pty as its controlling terminal, calls fork(2), sets up the execution environment as described above, and then uses the execve(2) system call to run the command in the child process. The monitor exists to relay job control signals between the user's existing terminal and the pty the command is being run in. This makes it possible to suspend and resume the command. Without the monitor, the command would be in what POSIX terms an “orphaned process group” and it would not receive any job control signals from the kernel.
- d0mine 8y ago
  The signal handling behavior may differ between versions e.g., https://stackoverflow.com/questions/34337840/cant-terminate-a-sudo-process-created-with-python-in-ubuntu-15-10 https://stackoverflow.com/questions/34337840/cant-terminate-...
jiveturkey 8y ago
deja vu. I remember having to dig into this behavior 10 years ago (maybe a tad more). Completely disagree with Teleport's fix and methodology. Sending remote SIGKILL because you got a local SIGINT? horrible for the general case. Now if Teleport performs specific functions for a specific controlled environment, then it might be fine and provide certain guarantees. But AFAICT teleport is a fronted to generic functionality.
jxy 8y ago
It's not anybody's fault. Everything is working exactly as it is supposed to do. Except for the leaky abstraction of a "pty". I wish there would be a better world than people constantly fighting for their terminal, TERM, terminfo, termcap, curses, tty, ...
JdeBP 8y ago
This is a fairly reasonable explanation, that is somewhat marred by two things. First, the suggestion to demonstrate non-canonical input mode with the stty command will not work for many people. Many shells that have command-line editing save and restore the termios settings before and after reading each line of interactive input. Run stty raw and stty sane from the Z shell, for example, and nothing at all will apparently change when typing input to ZLE. The same goes for the Bourne Again shell and Readline. Second, it keeps talking about a "local PTY device". The local end has a terminal, but that is not necessarily a pseudo terminal. It could be a real terminal, or a kernel virtual terminal.

russjones 8y ago

Author here, happy to answer any questions about the post.

yayana 8y ago
Is the double meaning of the headline intentional? I was expecting a timing or other attack to determine data has a particular origin..
- wyldfire 8y ago
  No it's [probably] not. SIGINT is unfortunately ambiguous, unlike SIGKILL, SIGTERM, SIGQUIT, SIGUSR1. :)
  - derefr 8y ago
    I'd have suggested "missing Ctrl+C" instead (like the title of the bug report.)
    - c12 8y ago
      As far as I know SIGINT is the name of the signal and Ctrl+C is simply a key combination that triggers it. I read the title to mean SIGINT the signal and it wasn't until I came to HN comments did I see have another meaning.
  - deleted 8y ago
    [deleted]
- russjones 8y ago
  Ha, nope, didn't realize this until everyone started mentioning it in the comments.

godelmachine 8y ago

I took SIGINT for Signal Intelligence

erric 8y ago
You're not the only one
dboreham 8y ago
Me too, since I date back to before signals had symbolic names.
bcaa7f3a8bbc 8y ago
Since 2013, I always have to double-check whether the context is Unix programming or mass surveillance when I encounter this term...

Drdrdrq 8y ago

I created an ssh terminal over browser back in the day (kind of like ajaxterm, but proprietary). I tried at least 4 different libraries over the years, but there would always be that one special device that refused to play ball. In the end I used an OpenSSH process, connected to it and drove it through input/output. Made those customer support calls really short: "Did you try connecting from the command line?"

kccqzy 8y ago

I've gradually learned to almost always allocate a PTY, whether it be ssh or some docker run. Too many programs work badly or unexpectedly differently when fd 0 or 1 is not a terminal. Maybe we should start collecting a hall of shame for programs that insist on dealing with a terminal, not just a pipe. Another fun fact I just came across a few weeks ago. The sudo command doesn't always handle job control signals in the way you expect it to. From its manual: > There are two distinct ways sudo can run a command. If an I/O logging plugin is configured or if the security policy explicitly requests it, a new pseudo-terminal (“pty”) is allocated and fork(2) is used to create a second sudo process, referred to as the monitor. The monitor creates a new terminal session with itself as the leader and the pty as its controlling terminal, calls fork(2), sets up the execution environment as described above, and then uses the execve(2) system call to run the command in the child process. The monitor exists to relay job control signals between the user's existing terminal and the pty the command is being run in. This makes it possible to suspend and resume the command. Without the monitor, the command would be in what POSIX terms an “orphaned process group” and it would not receive any job control signals from the kernel.

d0mine 8y ago
The signal handling behavior may differ between versions e.g., https://stackoverflow.com/questions/34337840/cant-terminate-a-sudo-process-created-with-python-in-ubuntu-15-10 https://stackoverflow.com/questions/34337840/cant-terminate-...

jiveturkey 8y ago

deja vu. I remember having to dig into this behavior 10 years ago (maybe a tad more). Completely disagree with Teleport's fix and methodology. Sending remote SIGKILL because you got a local SIGINT? horrible for the general case. Now if Teleport performs specific functions for a specific controlled environment, then it might be fine and provide certain guarantees. But AFAICT teleport is a fronted to generic functionality.

jxy 8y ago

It's not anybody's fault. Everything is working exactly as it is supposed to do. Except for the leaky abstraction of a "pty". I wish there would be a better world than people constantly fighting for their terminal, TERM, terminfo, termcap, curses, tty, ...

JdeBP 8y ago

This is a fairly reasonable explanation, that is somewhat marred by two things. First, the suggestion to demonstrate non-canonical input mode with the stty command will not work for many people. Many shells that have command-line editing save and restore the termios settings before and after reading each line of interactive input. Run stty raw and stty sane from the Z shell, for example, and nothing at all will apparently change when typing input to ZLE. The same goes for the Bourne Again shell and Readline. Second, it keeps talking about a "local PTY device". The local end has a terminal, but that is not necessarily a pseudo terminal. It could be a real terminal, or a kernel virtual terminal.