su or sudo?

Since ancient times, many have been confused by the variety of security options available when performing operations with maximum privileges. For example, in the official Ubuntu documentation, it is recommended that you use something like sudo nano as the editing sudo nano , and in numerous amateur manuals (in the style of “5 tricks on the command line that will surprise your grandmother”), you can write sudo su - to get the root shell. sudo su - . I will try to explain why this state of affairs seems to me wrong.

Historically, the only universal way to execute a command on behalf of another Unix user was the su program. Launched without parameters, it requested the superuser password and, if successful, simply replaced the current username with root, leaving almost all the environment variables from the old user (except PATH, USER and another two or three, see man su from the distribution). It was more correct to run it as su - - in this case, the shell also received the correct environment. With the -c option, you could run the command: su -c "vim /etc/fstab" .

At the same time, trusted users had to remember the root password and all users listed in the “wheel” group (i.e., a group whose members could execute the su command and become the superuser) had the same unlimited access to the entire system, which was a serious security issue.

Then the sudo command appeared, and it was a breakthrough. Now the administrator could specify the list of allowed commands for each user (or user group), editable files, special environment variables and much more (all this splendor is controlled from /etc/sudoers , see man sudoers from his distribution). When launched, sudo asks the user for his own password, not the root password. A full shell can be obtained using " sudo -i "
')
Special mention should be made of the special command sudoedit , which safely launches the editor specified in the $EDITOR environment $EDITOR . With a more traditional scheme, the files were edited like this:

  sudo vi / etc / fstab 

Launched in this way, vi inherits the shell with unlimited rights and through :! the user could run any command (unless, of course, the admin took care of this in advance) and open any file.

sudoedit checks if this user can change this file, then copies the specified file to a temporary directory, opens it in the editor (which inherits the rights of the user, not root), and after editing, if the file has been modified, with special precautions copies it back.

In Debian-based distributions, the root user does not have a password; instead, all administrative actions should be performed via sudo or its graphical equivalent gksudo . Being a complete substitute for su , sudo should be the only command switching between users, however, as was said at the beginning, at the moment it is not so and everyone for some reason inventing wild sequences from sudo, su, vi and dashes.

Therefore, I suggest everyone to remember once and for all:

What do we want to do?	right	wrong
run the command as root	sudo command	su -c "command"
edit the file as root	sudoedit file	su vim file sudo vim file
get root shell	sudo -i	su - sudo su -

After the first publication of this note, I was asked a few questions. From the answers it turned out to make a mini-FAQ.

Q: how to use sudo to make su -c "echo 1 > /etc/privileged_file" ? sudo echo 1 /etc/privileged_file swears at "permission denied"
A: This is because only the echo command is executed in elevated permissions, and the result is redirected to the file already with the rights of a regular user. To add something to privileged_file, you need to run the following command:

 $ echo 1 |  sudo tee -a privileged_file> / dev / null

Or temporarily become root:

 $ sudo -i
 # echo 1> privileged_file
 # exit
 $ 

Q: sudo -i longer than su - , and there seems to be no difference between them, why print more?
A: There are several advantages to sudo, for which it is worth working to type a few extra characters:

• by default, sudo logs all user activity to the authpriv syslog channel (as a rule, the result is put into the /var/log/auth.log file), and in su a similar feature must be enabled by setting a special parameter in the settings file that differs from the distribution kit to distribution kit ( SULOG_FILE in /etc/login.defs in Ubuntu Linux, /etc/login.conf and /etc/pam.d/su in FreeBSD, etc.)
• in the case of su, the system administrator cannot restrict the commands executed by users, but in sudo it can
• if the user should be deprived of administrative rights, in the case of su, after removing him from the wheel group, he must forget the root password; if sudo is used, it is sufficient to remove it from the corresponding group (for example, wheel or admin) and / or the sudoers file, if it has been additionally configured.

Q: I am the only user of my system and got used to su, why do I need sudo?
A: I will answer with a question: if there is a correct sudo, why use the outdated su?