Sudo Process Model, Signal Handling, and Plugins

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 options are enabled. Both pam_session and pam_setcred are enabled by default on systems using PAM. This mode is the default for sudo versions prior to 1.9.14 when using the sudoers policy. On systems that use PAM, the security policy’s close function is respon‐ sible for closing the PAM session. It may also log the command’s exit status. Signal handling When the command is run as a child of the sudo process, sudo will relay signals it receives to the command. The SIGINT and SIGQUIT signals are only relayed when the command is being run in a new pty or when the sig‐ nal was sent by a user process, not the kernel. This prevents the command from receiving SIGINT twice each time the user enters control‐C. Some signals, such as SIGSTOP and SIGKILL, cannot be caught and thus will not be relayed to the command. As a general rule, SIGTSTP should be used instead of SIGSTOP when you wish to suspend a command being run by sudo. As a special case, sudo will not relay signals that were sent by the command it is running. This prevents the command from accidentally killing itself. On some systems, the reboot(8) utility sends SIGTERM to all non‐system processes other than itself before rebooting the system. This prevents sudo from relaying the SIGTERM signal it received back to reboot(8), which might then exit before the system was actually re‐ booted, leaving it in a half‐dead state similar to single user mode. Note, however, that this check only applies to the command run by sudo and not any other processes that the command may create. As a result, running a script that calls reboot(8) or shutdown(8) via sudo may cause the system to end up in this undefined state unless the reboot(8) or shutdown(8) are run using the exec() family of functions instead of system() (which interposes a shell between the command and the calling process). Plugins Plugins may be specified via Plugin directives in the sudo.conf(5) file. They may be loaded as dynamic shared objects (on systems that support them), or compiled directly into the sudo binary. If no sudo.conf(5) file is present, or if it doesn’t contain any Plugin lines, sudo will use sudoers(5) for the policy, auditing, and I/O logging plugins. See the sudo.conf(5) manual for details of the /etc/sudo.conf file and the sudo_plugin(5) manual for more information about the sudo plugin archi‐ tecture. EXIT VALUE Upon successful execution of a command, the exit status from sudo will be the exit status of the program that was executed. If the command terminated due to receipt of a signal, sudo will send itself the same signal that terminated the

This section details how sudo executes commands without a PTY and the conditions under which it uses a close function. It also describes how sudo relays signals to the executed command, preventing self-termination and potential issues with reboot/shutdown utilities. The section also outlines how plugins are specified and loaded in sudo, using sudo.conf and the sudo_plugin architecture, defaulting to sudoers for policy, auditing, and I/O logging if no plugins are defined.