Execute commands as another identity
sudo command is used to execute commands with other identities. The default identity is root. The user who can execute sudo commands is set in /etc/sudoers
. If an unauthorized user attempts to use sudo, a warning email will be sent to the administrator. When using sudo, the user must first enter the password, and then there is a validity period of 5 minutes. After the period, the password must be re-entered.
sudo(options)(parameters)
-b: Execute instructions in the background;
-E: Inherit the current environment variables
-h: display help;
-H: Set the HOME environment variable to the HOME environment variable of the new identity;
-k: End the validity period of the password, that is, you need to enter the password the next time you execute sudo;.
-l: List the commands that the current user can and cannot execute;
-p: Change the prompt symbol for asking for password;
-s<shell>: execute the specified shell;
-u<user>: Use the specified user as the new identity. If this parameter is not added, root will be used as the new identity by default;
-v: Extend the password validity period by 5 minutes;
-V: Display version information.
Instruction: The instruction that needs to be run and the corresponding parameters.
$ sudo su -
# env | grep -E '(HOME|SHELL|USER|LOGNAME|^PATH|PWD|TEST_ETC|TEST_ZSH|TEST_PRO|TEST_BASH|TEST_HOME|SUDO)'
This command is equivalent to using the root super user to log in to the shell again, except that the password is the password of the current user. And importantly, this command will reload system configuration files such as the /etc/profile file and /etc/bashrc file, and will also reload the configuration file corresponding to the $SHELL environment variable of the root user, such as: root The super user's $SHELL is /bin/bash, and configurations such as /root/.bashrc will be loaded. If it is /bin/zsh, configurations such as /root/.zshrc will be loaded, and a complete root environment will be created after execution.
$ sudo -i
# env | grep -E '(HOME|SHELL|USER|LOGNAME|^PATH|PWD|TEST_ETC|TEST_ZSH|TEST_PRO|TEST_BASH|TEST_HOME|SUDO)'
This command is basically the same as sudo su -
. After execution, it will also be the root super user environment, but with some additional information about the current user.
$ sudo -s
# env|grep -E '(HOME|SHELL|USER|LOGNAME|^PATH|PWD|TEST_ETC|TEST_ZSH|TEST_PRO|TEST_BASH|TEST_HOME|SUDO)' --color
This command is equivalent to opening a no-login shell of the root super user with the current user's $SHELL, and will not load system configurations such as /etc/profile. Therefore, the TEST_ETC environment variable defined in the /etc/profile file cannot be seen, but the configuration file corresponding to the root user will be loaded. For example, if the root user's $SHELL is /bin/zsh, then /root/ will be loaded. After the zshrc configuration file is executed, the current user's directory will not be switched.
Configuring sudo must be done by editing the /etc/sudoers
file, and only super users can modify it. It must also be edited using visudo. There are two reasons why visudo is used. First, it can prevent two users from modifying it at the same time; second, it can also perform limited syntax checking. So, even if you are the only super user, you'd better use visudo to check the syntax.
By default, visudo opens the configuration file in vi and uses vi to modify the file. We can modify this default item at compile time. Visudo will not save configuration files with syntax errors without authorization. It will prompt you about the problems and ask how to deal with them, like:
>>> sudoers file: syntax error, line 22 <<
At this point we have three options: type "e" to re-edit, type "x" to exit without saving, type "Q" to exit and save. If Q is selected, sudo will not run again until the error is corrected.
Now, let's take a look at the mysterious configuration file and learn how to write it. Let's start with a simple example: let user Foobar execute all root-executable commands through sudo. Open the configuration file with visudo as root, you can see lines similar to the following:
# Runas alias specification
# User privilege specificationroot ALL=(ALL)ALL
We will understand at a glance that root has all permissions. Just follow the existing root example. We add a line below (it is best to use tab as a blank):
foobar ALL=(ALL) ALL
After saving and exiting, switch to user foobar, and we execute the command as it:
[foobar@localhost ~]$ ls /root
ls: /root: Insufficient permissions
[foobar@localhost ~]$ sudo ls /root
PassWord:
anaconda-ks.cfg Desktop install.log install.log.syslog
Okay, let's restrict foobar's rights and prevent him from doing whatever he wants. For example, if we just want him to use ls and ifconfig like root, change that line to:
foobar localhost= /sbin/ifconfig, /bin/ls
Then execute the command:
[foobar@localhost ~]$ sudo head -5 /etc/shadow
Password:
Sorry, user foobar is not allowed to execute '/usr/bin/head -5 /etc/shadow' as root on localhost.localdomain.
[foobar@localhost ~]$ sudo /sbin/ifconfigeth0 Linkencap:Ethernet HWaddr 00:14:85:EC:E9:9B...
Now let's take a look at what those three ALL mean. The first ALL refers to the host in the network. We later changed it to the host name. It indicates that foobar can execute subsequent commands on this host. ALL in the second bracket refers to the target user, that is, who is the identity to execute the command. The last ALL, of course, refers to the command name. For example, if we want user foobar to execute the kill command as jimmy or rene on the Linux host, write the configuration file like this:
foobar linux=(jimmy,rene) /bin/kill
But there is still a question, does foobar execute as jimmy or rene? At this time we should think of sudo -u
, which is used exactly at this time. foobar can use sudo -u jimmy kill PID
or sudo -u rene kill PID
, but this is very troublesome. In fact, we don’t need to add -u
every time and set rene or jimmy as the default target user. . Add another line above:
Defaults:foobar runas_default=rene
If there is a colon after Defaults, it is the default for subsequent users. If there is not, it is the default for all users. Just like the line that comes with the configuration file:
Defaults env_reset
Another problem is that many times, we have already logged in, and it is cumbersome to enter the password every time we use sudo. Can we stop entering passwords? Of course, we can modify the configuration file like this:
foobar localhost=NOPASSWD: /bin/cat, /bin/ls
Let’s sudo again:
[foobar@localhost ~]$ sudo ls /rootanaconda-ks.cfg Desktop install.log
install.log.syslog
Of course, you can also say "certain commands cannot be run as user foobar" by using the ! operator, but this is not a good idea. Because using the ! operator to "eliminate" some commands from ALL generally has no effect, a user can copy that command to another place, change its name, and then run it.
Logs and Security
sudo is very considerate for security. It can not only record logs, but also report to the system administrator when necessary. However, sudo's logging function is not automatic and must be enabled by the administrator. To do it this way:
touch /var/log/sudo
vi /etc/syslog.conf
Add a line at the end of syslog.conf (must be separated by tabs) and save:
local2.debug /var/log/sudo
Restart the log waiting process,
ps aux grep syslogd
Fill in the PID of the syslogd process obtained (the second column of the output is the PID):
kill –HUP PID
In this way, sudo can write logs:
[foobar@localhost ~]$ sudo ls /rootanaconda-ks.cfg
Desktop install.log
install.log.syslog
$cat /var/log/sudoJul 28 22:52:54 localhost sudo: foobar :
TTY=pts/1 ; pwd=/home/foobar ; USER=root ; command=/bin/ls /root
However, there is a small "flaw", sudo logging is not very faithful:
[foobar@localhost ~]$ sudo cat /etc/shadow > /dev/null
cat /var/log/sudo...Jul 28 23:10:24 localhost sudo: foobar : TTY=pts/1;
PWD=/home/foobar; USER=root; COMMAND=/bin/cat /etc/shadow
Redirects are not logged! Why? Because the shell has completed the redirection before the command is run, sudo does not see the redirection at all. This also has the advantage that the following methods will not succeed:
[foobar@localhost ~]$ sudo ls /root > /etc/shadowbash: /etc/shadow: Insufficient permissions
sudo has its own way of maintaining security. Execute sudo-V
as root and check the sudo settings. Because of security issues, some environment variables are not passed to the command after sudo, or are passed after being checked, such as: PATH, HOME, SHELL, etc. Of course, you can also configure these environment variables through sudoers.