выполнить команду от имени другого пользователя (execute a command as another user)
Выполнение команд (Command execution)
When sudo executes a command, the security policy specifies the
execution 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)
• 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 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
itself as the leader and the pty as its controlling terminal, calls
fork(2), 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 existing terminal and the pty the command is being run
in. This makes it possible to suspend and resume the command.
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 receiving the command's exit
status, the main sudo passes the command's exit status to the
security policy's close function and exits.
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 security policy's close function 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, or the
pam_session or pam_setcred options are enabled. Note that
pam_session and pam_setcred are enabled by default on systems using
PAM.
On systems that use PAM, the security policy's close function is
responsible 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 signal 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)
command 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 rebooted, 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).
If no I/O logging plugins are loaded and the policy plugin has not
defined a close() function, set a command timeout or required that
the command be run in a new pty, sudo may execute the command
directly instead of running it as a child 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 architecture.
