Previously, we compared the terminal device number returned by
get_process_ttyname() with that of stdin, stdout and stderr. This
causes problems on Linux if the user is logged in on the console,
which is a virtual device that may correspond to one of several
different terminal devices. In this specific case, there is a
mismatch between the controlling terminal listed in /proc/self/stat
(which corresponds to the underlying terminal device) and the device
number of stdin, stdout and stderr (which is that of /dev/console).
We rely on the include path to find many of these headers. It
especially doesn't make sense to use #include "foo.h" for headers
in the top-level include directory.
Previously, sudo only checked that the fd was a terminal, not that
it matched sudo's idea of the user's terminal. This matters when
input or output is redirected to a different terminal. In that
case we want to interpose the fd with a pipe even if it refers to
a terminal. Bug #1056.
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.
This should reduce the amount of time the child has to wait for
the parent to use PTRACE_SEIZE to seize control and then PTRACE_CONT
to continue the child.
The code to take back control of the tty before a policy check
doesn't appear to be needed. If the command is run in its own pty,
sudo has control over the user's tty. If the command is run in
the user's tty, sudo should be in the foreground process group.
The special value "user" means preserve the invoking user's limit.
The value "default" means don't override the default limit for the
user as assigned by the system (PAM, loging.conf, userdb, etc).
Fixes building on Solaris and probably others. It is possible to
expose msg_control on Solaris but this requires a specific set of
feature flag defines which can cause other complications.
Previously we needed to include headers required by the various
sudo*h files. Now those files are more self-sufficient and we
should only include headers needed by code in the various .c files.
This prevents another process from changing the NOFILE resource limit
of the child process and defeating the closefrom() call.
Reported by Joe Vennix from Apple Information Security.
