On Linux and other Unix-based operating systems, sudo is used to run a program with the privileges of another user, often root. When we need to modify a file which requires administrative privileges to be edited, if we launch our favourite text editor directly with sudo, it will run without the customization and settings we use when we invoke it normally, since the environment of the invoking user is not preserved. In this tutorial we will see how can we easily solve this problem and how we can modify system files securely by using sudoedit.
In this tutorial you will learn:
- How to edit a system file using sudoedit
- What are the steps performed when a file is edited with sudoedit
- How to set the default editor used by sudo
Software requirements and conventions used
|Category||Requirements, Conventions or Software Version Used|
|Conventions||# – requires given linux-commands to be executed with root privileges either directly as a root user or by use of
$ – requires given linux-commands to be executed as a regular non-privileged user
Sudo standard behavior
The majority of Linux distributions are configured so that the main way to achieve root privileges is to use sudo. The use of sudo grants us a series of privileges over
su, the main one being that specific privileges can be granted to one user without having to give him full root access.
Sudo can be fine-tuned via the
/etc/sudoers file; since this file is very important, it should be edited using the
visudo command, which does ensure no syntax errors are present before changes are saved.
In the vast majority of cases, when a command is run with sudo, the invoking user environment is not preserved, so for example, if we invoke our editor using sudo to modify a system file owned by root, it will run ignoring our personal setup. This can be rather inconvenient, and in certain cases running an editor with escalated privileges can pose some security issues. Let’s see what we can do, instead.
The problem: the editor is launched without user-defined settings
Suppose we must edit a file with administrative privileges, say for example
/etc/fstab, which is where the static information about filesystems are stored on Linux. If we use our favorite text editor and invoke it directly using sudo,
the customization we set to it (typically via the appropriate dotfiles stored in our
HOME directory) will not be honored, since the invoking user environment is not be preserved.
Let’s see an example. Say our favorite editor is Vim and in our
~/.vimrc file we entered the
set number directive which causes line numbers to be displayed. If we edit the
/etc/fstab file invoking the editor directly with sudo, we can see the settings are not effective:
$ sudo vim /etc/fstab
The file will be opened in the editor, and the following is what will be displayed. The content of the file doesn’t matter to us in this case, so it is truncated:
# # /etc/fstab # # Accessible filesystems, by reference, are maintained under '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info. # # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. # /dev/mapper/fingolfin_vg-root_lv / ext4 defaults,x-systemd.device-timeout=0 1 1 UUID=b308fbe5-68a6-4142-82de-ba1dc3380484 /boot ext2 defaults 1 2 [...]
As you can see line numbers are not displayed. The above is just an example and probably our editor customizations go far beyond that. How can we solve this problem?
The solution: using sudoedit
To solve the problem we illustrated above, we can simply use
sudoedit instead of
sudoedit is the equivalent of invoking
sudo with the
-e option, which is the short for
--edit. As stated in the
sudo manual, this option basically means: “edit a file instead of running a command”.
When this strategy is used, and the invoking user is permitted to perform the action by the system policy, a series of steps will be performed. First of all, a temporary copy of the file we want to edit is created. The temporary file will be owned by the invoking user, so no administrative privileges will be required in order to modify it.
The temporary file will be opened in the default text editor. The default editor is set via some variables, which are read in a specific order. They are:
Depending on the distribution and shell we are using, the value of this variables can be set permanently in the
~/.bash_profile (only sourced by the bash shell) or the
~/.profile file. To set
vim as our default editor, for example, we would write:
Notice that we used the
export shell built-in before the variable definition: it is needed to export the variable itself to all the child processes of the shell. The changes will not be immediately effective: we should logout and login again,
or source the modified file “manually”:
$ source ~/.bash_profile
If none of these variables is set, the first editor specified as the value of the
editor option in the sudoers file (
/etc/sudoers) will be used.
Once the file we modified is saved (it will be created from scratch if doesn’t already exist), and the editor is closed, it will be copied back to the original position, and the temporary file will be removed. The user will be prompted to
confirm the action if the edited file becomes empty; this is an additional and very useful security measure, which can prevent catastrophic mistakes:
sudoedit: truncate /etc/fstab to zero bytes? (y/n) [n] n sudoedit: not overwriting /etc/fstab
Since When using
sudoedit instead of
sudo the environment of the invoking user is preserved and the file is edited as the user itself and not as root, we will be able to use our editor with all the customization we set, included loaded plugins.
In this tutorial we learned how is possible to edit a file which requires administrative privileges to be modified while keeping the invoking user environment using sudoedit instead of sudo. We saw what are the advantages of this approach, what are the steps performed when it is adopted, and how to set the default editor used by sudo.