1. The admin:// URI
In Ubuntu, the official way to edit system files as root with a graphical editor is to use the admin://
URI. For example, to edit /etc/fstab
, issue the following command in the run dialog you obtain after pressing Alt+F2 or on the terminal:
gedit admin:///etc/fstab
In older Ubuntu versions (prior to 20.10), the very first time you do this, you need to supply your user password two times in a row. This has been fixed in 20.10.
Of course, your user needs to belong to the root group in order to edit system files.
2. Using sudoedit
An approach valid for any desktop environment with any editor would be to use sudoedit
. Setup the SUDO_EDITOR environment variable to point to the binary of your graphical editor, for example: export SUDO_EDITOR="/usr/bin/gedit"
. Then, you can use the command sudoedit <file>
or sudo -e <file>
to open a system file in your graphical editor. Much the way the admin:// URI does, this will create a temporary copy, which you edit as a normal user. Once the editor is closed, the modified temporary copy is copied back over the system file.
This can actually be combined in a single command:
env SUDO_EDITOR="/usr/bin/gedit" sudoedit <file>
Thus, the environment is changed only when you explicitly want to use the graphical editor. You create an alias or create a small script to edit system text files in a graphical editor with a single command.
3. Discouraged: using pkexec
These two options do not at any time run your graphical editor as root, which is preferred. Still, it is possible to run a graphical editor as root using pkexec
. You can install a PolicyKit file, but you also may run it with some environment variables. For nautilus
users, the package nautilus-admin
installs a PolicyKit file for gedit and provides a right-click menu option in nautilus
to launch a text file in gedit
with root permissions. However, these options, where a graphical application is run as root are, according to man pkexec
, discouraged:
As a result, pkexec will not allow you to run X11 applications
as another user since the $DISPLAY and $XAUTHORITY environment
variables are not set. These two variables will be retained if the
org.freedesktop.policykit.exec.allow_gui annotation on an action is set
to a nonempty value; this is discouraged, though, and should only be
used for legacy programs.
pkexec gedit
.sudo gedit /path/to/file
? It's probably not the greatest way to do it, but it works for me.xhost si:localuser:root
). This solution does work, but it poses a serious security risk. And the latter is what I would prefer to avoid, if possible.