Sudo Plugins, Exit Values, and Security Notes

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 command. If the -l option was specified without a command, sudo will exit with a value of 0 if the user is allowed to run sudo and they authenticated successfully (as required by the security policy). If a command is specified with the -l option, the exit value will only be 0 if the command is permitted by the security policy, otherwise it will be 1. If there is an authentication failure, a configuration/permission prob‐ lem, or if the given command cannot be executed, sudo exits with a value of 1. In the latter case, the error string is printed to the standard error. If sudo cannot stat(2) one or more entries in the user’s PATH, an error is printed to the standard error. (If the directory does not exist or if it is not really a directory, the entry is ignored and no error is printed.) This should not happen under normal circumstances. The most common reason for stat(2) to return “permission denied” is if you are running an automounter and one of the directories in your PATH is on a machine that is currently unreachable. SECURITY NOTES sudo tries to be safe when executing external commands. To prevent command spoofing, sudo checks "." and "" (both denoting cur‐ rent directory) last when searching for a command in the user’s PATH (if one or both are in the PATH). Depending on the security policy, the user’s PATH environment variable may be modified, replaced, or passed unchanged to the program that sudo executes. Users should never be granted sudo privileges to execute files that are writable by the user or that reside in a directory that is writable by the user. If the user can modify or replace the command there is no way to limit what additional commands they can run. By default, sudo will only log the command it explicitly runs. If a user runs a command such as ‘sudo su’ or ‘sudo sh’, subsequent commands run from that shell are not subject to sudo’s security policy. The same is true for commands that offer shell escapes (including most editors). If I/O logging is enabled, subsequent commands will have their input and/or output logged, but there will not be traditional logs for those commands. Because of this, care must be taken when giving users access to commands via sudo to verify that the command does not inadvertently give the user an effective root shell. For information on ways to ad‐ dress this, see the Preventing shell escapes section in sudoers(5). To prevent the disclosure of potentially sensitive information, sudo disables core dumps by default while it is executing (they are re‐en‐ abled for the command that is run). This historical practice dates from a time when most operating

This section describes how plugins can be specified and loaded in sudo via the sudo.conf file. It details the exit values of sudo based on the success of command execution, authentication, and configuration. Furthermore, it emphasizes security notes, including path checking to prevent command spoofing, restricting sudo access to user-writable files, logging limitations with shell commands, and disabling core dumps for sensitive information protection.