How to edit a system file with sudoedit preserving the invoking user environment

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

Software Requirements and Linux Command Line Conventions
Category Requirements, Conventions or Software Version Used
System Distribution independent
Software sudo
Other None

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/'.
# 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 sudo. Using 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:

export SUDO_EDITOR=/usr/bin/vim

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.

Comments and Discussions
Linux Forum