Previously, we only did this when running in the foreground but
this can cause problems when running a program that reads the
terminal settings or window size in the background. If sudo is
running in the background, the terminal settings will be updated
if it transitions to the foreground process.
Based on a suggestion from From Duncan Overbruck.
While we cannot catch SIGSTOP, we _can_ catch SIGCONT and set
/dev/tty to raw mode when running in the foreground. Ignore SIGCONT
in suspend_sudo_pty() so we don't call resume_terminal() twice.
This fixes a hang when there is /dev/tty data in a buffer to be
flushed by the final call to del_io_events(). We do not want to
re-enable the reader when flushing the buffers as part of pty_finish().
See PR #247 for analysis of the problem and how to reproduce it.
If sudo is not the process group leader and stdin is not a tty, we
may be running as a background job via a shell script. Start the
command in the background to avoid changing the terminal mode from
a background process. GitHub issue #237
When sudo is not the process group leader, we still need to stop
sudo's process group and not just the sudo process itself. If we
only send the signal to sudo itself, the shell will not notice if
it is not in monitor mode. This can happen when sudo is run from
a shell script, for example. In this case we need to signal the
shell itself. If the process group leader is no longer present,
we must kill the command since there will be no one to resume us.
If sudo is not the process group leader we must only send the suspend
signal to sudo itself. When sudo is run via a shell script, it
usually has the same process group as the shell script interpreter.
We do not want to suspend the script itself when the command run
by sudo is suspended.
If we are logging I/O but not terminal input/output (either because
no terminal is present or because that is what the plugin requested),
the non-pty exec path is now taken.
This will be shared with exec_nopty.c in the future to log
stdin/stdout/stderr without running the command in a pty.
Both exec_pty.c and exec_nopty.c now use the same closure.
When ptracing a process, we receive the signal-delivery-stop signal
before the group-stop signal. If sudo is running the command in
the same terminal, we need to wait until the stop signal is actually
delivered to the command before we can suspend sudo itself. If we
suspend sudo before receiving the group-stop, the command will be
restarted with PTRACE_LISTEN too late and will miss the SIGCONT
from sudo.
This allows intercept mode to work with shells that close all open
fds upon startup. The ctor in sudo_intercept.so requests the port
number and secret over the socket inherited from the parent then
closes it. For each policy request, a TCP connection is made to
the sudo parent process to perform the policy check. Child processes
re-use the TCP socket to request the port number and secret just like
the initial process started by sudo does.
The goal is to make it harder for someone to have a fake policy checker.
This will not stop a determined adversary since the secret is present
in the address space of the running process.
This should only be set for signals that terminate the process.
Fixes a bug where the sudo front-end could call the plugin close
function with a non-terminal signal argument.
This fixes an issue on Solaris 11.4 (and probably others) with "sudo
reboot" when I/O logging is enabled. Previously, sudo would kill
the command if it was still running after the event loop terminated,
leaving the system in a half-dead state.
Fixes a problem on Solaris 11.4 (and possibly others) where sudo
continually tries to put itself in the background after the user's
terminal has been revoked.
We currently have no good way to distinguish between an error
executing the command and an error while the command is running.
In the future, we should have additional status codes so we
can tell what type of condition caused the loop to exit.
For now, only kill the command if cstat is left uninitialized.
