Nmap Development mailing list archives

Re: [patch] The most minor issue ever: set noninteractive on -iL -


From: Patrick Donnelly <batrick () batbytes com>
Date: Fri, 6 Apr 2012 23:00:40 -0400

On Fri, Apr 6, 2012 at 8:41 PM, David Fifield <david () bamsoftware com> wrote:
On Fri, Apr 06, 2012 at 05:36:24PM -0700, David Fifield wrote:
On Tue, Apr 03, 2012 at 10:50:03PM -0400, Patrick Donnelly wrote:
On Tue, Apr 3, 2012 at 9:17 PM, David Fifield <david () bamsoftware com> wrote:
I tried this (getpgrp) but it didn't seem to change anything.

I just double-double checked and got it to work:

I'm using this patch (make sure to change both calls to getpid):

I think that was my mistake: I changed only one of them. It's working
for me; will you commit it?

Actually, I just tried this:

sudo ./nmap scanme.nmap.org

And I get runtime interaction, but then my terminal stops echoing after
Ctrl-C.

Okay, after some investigation, I've found the cause(s):

(a) Nmap uses an atexit handler to reset the terminal settings. In the
event of abnormal termination caused by SIGINT (or other signals),
this atexit handler is never called. This is the root of the problem
but there are other interesting interactions worth looking at...

(b) When Bash is run in interactive mode and sees a child of a job
ends abnormally, it resets the terminal settings. So for commands like
'nmap scanme.nmap.org' or 'echo scanme.nmap.org | nmap -iL
/dev/stdin', it can tell that nmap fails due to SIGINT and so resets
the terminal settings. This happens even when you do not send SIGINT
via the terminal using ctrl+c. For example, try this:

$ strace -f -o OUTPUT /bin/bash --login -i -c 'echo scanme.nmap.org |
./nmap --datadir . -iL - --scan-delay 10ms; echo done' # foreground of
one tty
$ killall -SIGINT nmap # in another tty


Now, if you try instead:

$ sudo strace -f -o READ /bin/bash --login -i -c 'echo scanme.nmap.org
| sudo ./nmap --datadir . -iL - --scan-delay 10ms; echo done'
$ killall -SIGINT nmap # in another tty

The terminal settings are not reset (because sudo exits normally even
if nmap does not).

[
Some specifics:

Bash resets the terminal settings if run in interactive mode and any
child in a job dies abnormally. In the case of sudo, bash doesn't know
that nmap dies because bash is not aware of children sudo forks.

Here's the relevant code:

      if (interactive_shell && subshell_environment == 0)
    {
      /* This used to use `child->status'.  That's wrong, however, for
         pipelines.  `child' is the first process in the pipeline.  It's
         likely that the process we want to check for abnormal termination
         or stopping is the last process in the pipeline, especially if
         it's long-lived and the first process is short-lived.  Since we
         know we have a job here, we can check all the processes in this
         job's pipeline and see if one of them stopped or terminated due
         to a signal.  We might want to change this later to just check
         the last process in the pipeline.  If no process exits due to a
         signal, S is left as the status of the last job in the pipeline. */
      s = job_signal_status (job);

      if (WIFSIGNALED (s) || WIFSTOPPED (s))
        {
          set_tty_state ();

          /* If the current job was stopped or killed by a signal, and
         the user has requested it, get a possibly new window size */
          if (check_window_size && (job == js.j_current || IS_FOREGROUND (job)))
        get_new_window_size (0, (int *)0, (int *)0);
        }

The call to set_tty_state resets the state to what it was before the job died.

]

[Note also, we don't see this problem with sudo for the current nmap
because tcgetpgrp != getpid().]

So anyway, we've been up to now enjoying the shell cleaning up after
us. I think what we need is a signal handler for SIGINT, SIGQUIT, and
SIGTERM which clean up the terminal settings. Shall I write up a patch
for this?

-- 
- Patrick Donnelly
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/


Current thread: