caused  by  poorly written scripts that invoke sudo with user‐controlled
       input.

       Environment variables to be set for the command may also  be  passed  as
       options    to    sudo    in    the    form    VAR=value,   for   example
       LD_LIBRARY_PATH=/usr/local/pkg/lib.  Environment variables may  be  sub‐
       ject to restrictions imposed by the security policy plugin.  The sudoers
       policy  subjects environment variables passed as options to the same re‐
       strictions as existing environment variables with one important  differ‐
       ence.  If the setenv option is set in sudoers, the command to be run has
       the SETENV tag set or the command matched is ALL, the user may set vari‐
       ables that would otherwise be forbidden.  See sudoers(5) for more infor‐
       mation.

COMMAND EXECUTION
       When  sudo  executes a command, the security policy specifies the execu‐
       tion environment for the command.  Typically,  the  real  and  effective
       user  and  group  and  IDs are set to match those of the target user, as
       specified in the password database, and the group vector is  initialized
       based on the group database (unless the -P option was specified).

       The following parameters may be specified by security policy:

       •  real and effective user‐ID

       •  real and effective group‐ID

       •  supplementary group‐IDs

       •  the environment list

       •  current working directory

       •  file creation mode mask (umask)

       •  SELinux role and type

       •  scheduling priority (aka nice value)

   Process model
       There are two distinct ways sudo can run a command.

       If  an  I/O  logging plugin is configured to log terminal I/O, or if the
       security policy explicitly requests it, a new pseudo‐terminal (“pty”) is
       allocated and fork(2) is used to create a second sudo process,  referred
       to  as the monitor.  The monitor creates a new terminal session with it‐
       self as the leader and  the  pty  as  its  controlling  terminal,  calls
       fork(2) again, sets up the execution environment as described above, and
       then  uses  the  execve(2)  system  call to run the command in the child
       process.  The monitor exists to relay job control  signals  between  the
       user’s  terminal and the pty the command is being run in.  This makes it
       possible to suspend  and  resume  the  command  normally.   Without  the
       monitor,  the  command would be in what POSIX terms an “orphaned process
       group” and it would not receive any job control signals from the kernel.
       When the command exits or is terminated by a signal, the monitor  passes
       the command’s exit status to the main sudo process and exits.  After re‐
       ceiving  the  command’s  exit  status,  the main sudo process passes the
       command’s exit status to the security policy’s close function,  as  well
       as  the  close function of any configured audit plugin, and exits.  This
       mode is the default for sudo versions 1.9.14 and above  when  using  the
       sudoers policy.

       If no pty is used, sudo calls fork(2), sets up the execution environment
       as  described  above,  and  uses  the  execve(2)  system call to run the
       command in the child process.  The main sudo  process  waits  until  the
       command  has completed, then passes the command’s exit status to the se‐
       curity policy’s close function, as well as the  close  function  of  any
       configured  audit  plugins, and exits.  As a special case, if the policy
       plugin does not define a close function, sudo will execute  the  command
       directly  instead  of  calling fork(2) first.  The sudoers policy plugin
       will only define a close function when I/O logging is enabled, a pty  is
       required,  an  SELinux  role is specified, the command has an associated
       timeout, or the pam_session or pam_setcred