We know that - aside from
SIGSTOP - a program can intercept IPC signals, and run its internal handler circumventing the operation of the default handler.
I can think of at least one very good reasons for doing this with the
- Namely implementing a signal handler that executes either a last ditch backup, saves a memory dump, or writes to log, before reverting to the default signal operation that terminates the process.
I can also think of a good reason why a piece of malware might catch and block SIGINT:
Namely to extend the execution time of the process . For the majority of users,Ctrl+C is the go to keyboard shortcut for most terminal users and there are many that are unaware of Ctrl+Z (
SIGTSTPwhich only stops the process, which remains among terminal
jobs), not to mention Ctrl+\ , which sends the
SIGQUITand creates a core dump.
If Ctrl+C gets caught and blocked, such users will likely try to open another terminal window, and run something along the lines of:
ps aux | grep [process name]
get the process PID, and execute the SIGKILL with
kill -9 [$PID]
Similarly, users connecting to a terminal session on a remote machine, will attempt to make a second connection with a new terminal session, and go through a similar process/PID search in order to terminate the culprit. Obviously, this tactic might extend the process runtime by only a short period, but even extra 3 minutes of a file transferring process using a high bandwidth connection of 10MB/s will transfer almost 2 GB of additional data, so there is certainly some merit to it.
However, recently I have noticed - perhaps only because I started paying attention to it - that there are programs that seemingly fall into another subset.
These programs, which are open-source and have packages maintained and examined closely enough that hiding a major piece of malware code seems highly unlikely.
They do not take control of keyboard input like
vimand other text editors
They have internal handlers that catch SIGINT and ignore it completely. There is no eventual process termination and to the best of knowledge no last ditch critical tasks are attempted.
Is there a possible reason why a process might choose to intercept but drop SIGINT completely for a legitimate purpose?
In other words, can there be a good reason (from a code or system standpoint) or situation when catch and ignore of SIGINT is more advantageous than its known default operation that would terminate the running process?