These are not actually errors but can help gain insight into what
is going on and, in the case of EAGAIN, whether or not there may
be a kernel resource starvation problem.
We can skip the policy check for the execve(2) of the initial command
since it has already been check. Otherwise, we would log the command
twice. When using fexecve(2) due to a digest check, there should
be no need to skip the initial command since it will be executed
via execveat(2) not execve(2). However, on older kernels without
execveat(2), glibc will emulate fexecve(2) using /proc which will
result in the extra log entry.
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.
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.
