Score:3

What is the recommended way to use a GUI editor to view system files?

pe flag

Gnome enforces barriers to viewing files requiring root privileges. Trying to open /var/log/boot.log file with gedit fails, with no visible option to perform this action as root from the GUI file manager. What is the Gnome doctrine for dealing with situations like this? I know that I can use sudo gedit, but that makes it more cumbersome than launching an application from Nautilus, pardon me, Files.


A close-to-ideal solution is provided by Nemo, the file manager in the Cinnamon desktop. It gives you an option to open a directory as a root, and then you can open this file with a text editor.

Another option is to enforce permissions in the editor on file save, not on file open. It could allow opening any file in read-only mode, which doesn't present any safety concern. This used to be done in the past somewhere. The current design is unnecessarily authoritarian.

David Z avatar
es flag
FWIW KDE's text editors (Kwrite and Kate) do allow opening files in read-only mode, and will do exactly that when you open a file you don't have write permission for. So this isn't an issue with GUI editors in general, it's just about gedit.
in flag
The issue here is not necessarily gedit, `/var/log/boot.log` is not _readable_ by non-root users on most Ubuntu systems, so even using Kate (or gvim, or some other editor) will not allow you to open it as a regular user).
David Z avatar
es flag
In that case the whole last paragraph of the question is irrelevant and misleading. In fact, I'd argue the title is misleading as well, because it asks about "system files", which is a very different category from "non-world-readable files" - many system files are readable (but not writable) by any user.
in flag
@DavidZ Agreed, but a lot of less experienced users do not make that kind of distinction, so I would argue that the question is still relevant as titled. And the final paragraph is technically correct AIUI (and, IMO, poor design on the part of the gedit developers), even if it does not happen to be directly relevant to the particular example case listed earlier in the question.
Paul Jurczak avatar
pe flag
@DavidZ I just installed Kate on Mint 21 and it doesn't allow to open `/var/log/boot*` files, just like gedit.
Score:10
us flag

On the command line, type:

gedit admin://<full path to file>

You will be prompted for your sudo user password in a popup dialog. After you enter it correctly, your file will open in gedit.

For example:

gedit admin:///var/log/boot.log
Paul Jurczak avatar
pe flag
This is more cumbersome than just `sudo gedit`.
Organic Marble avatar
us flag
@PaulJurczak what is your criterion for an acceptable level of effort?
Paul Jurczak avatar
pe flag
@OrganicMarble The same user input as for user files + entering root password.
rs flag
@PaulJurczak I guess the only difference is that `sudo gedit` may run `gedit` with different env vars/settings than a normal gedit instance while `gedit admin://` should run with exactly the same settings? Anyway yes, it doesn't save much else other than (possibly) that.
danzel avatar
cn flag
+1, but I'm curious where this recommendation comes from. I guess it's some gvfs magic, but a documentation link would be nice.
Score:7
us flag

I added this as a separate answer, since you mentioned you would like a more convenient (less "cumbersome") way of editing files as root.

You can use the nautilus-admin extension.

This extension adds a right-click context menu item called "Edit as Administrator" to Nautilus. Just right click on the file you want to edit as root, and select this option.

The best way to install this extension is:

sudo apt install nautilus-admin

The recommended technique to edit files as root is to use gedit admin://, as indicated in my other answer. This extension does exactly the same thing, but you don't have to open a terminal and type the command yourself.

Paul Jurczak avatar
pe flag
Your other answer was more direct (recommended way), but I'm choosing this one as more practical (convenient way). Thank you.
Score:4
us flag

You can make a small script to reduce the overhead, like this.

#!/bin/bash

absolute_name=$(realpath "$1")

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY gedit "$absolute_name"

Put the script somewhere in your path and make it executable. For the purpose of demonstration, I called it ggedit.

So you just type (for example)

ggedit /etc/fstab

An authorization window will open, you type in your password, and it opens the file as the superuser.

Source: I almost certainly got this off Ask Ubuntu in the past decades, but I no longer know where

Score:2
cn flag

What is the Gnome doctrine for dealing with situations like this?

The most "official" statement I could find was this page on help.gnome.org:

Edit a file as the root user

It starts with a bold disclaimer:

Editing files as the root user is potentially dangerous, and may break your system in bad ways. Take great care when editing files as the root user.

Their suggestion is to launch gedit from a terminal as the root user:

sudo gedit

Another option is to enforce permissions in the editor on file save, not on file open

In your particular example, this is not possible because /var/log/boot.log is not readable by any user except root. So in order to display its contents, any application would require root privileges.

You may be able to combine @Organic Marble's answer with a .desktop file, so you could right-click -> Open with -> root gedit.

For the (probably) more common case when you want to edit a file that is owned by root and readable by your user, e.g. most config files in /etc, I personally use Kate. It opens the file as your current user, and asks for your password when you attempt to save it. It does require the whole KDE/Qt ecosystem though, which may or may not be acceptable for you.

us flag
It is best to not open graphical applications using `sudo`. See [Why should users never use normal sudo to start graphical applications?](https://askubuntu.com/q/270006/100356) for more information.
terdon avatar
cn flag
@Enterprise that doesn't seem to be true anymore as explained in the accepted answer of the very question you linked to. This was always an Ubuntu strangeness and they finally realized it was a bad idea a few years ago and no longer do it. Also see [How does sudo handle $HOME differently since 19.10?](https://askubuntu.com/q/1186999)
us flag
@terdon, thanks for the link. I think there is still some (perhaps minor?) [concern](https://askubuntu.com/a/270019/100356)... "That still won't automatically handle the ownership of .Xauthority [...] in the infrequent event that .Xauthority is inaccessible, you'll get an error saying it is, and then you can fix the problem by deleting it (sudo rm ~/.Xauthority)". Personally, I still use the `admin:` technique or `sudo nano` just to be safe.
terdon avatar
cn flag
@Enterprise no, there is no concern. That answer is outdated: please read the warning at the beginning and the other post I linked to. Ubuntu's `sudo` _finally_ no longer keeps `$HOME` pointing to the `$SUDO_USER`'s home but instead `$HOME` is now `/root`, as it should be, so all of these problems have gone away.
Paul Jurczak avatar
pe flag
*Editing files as the root user is potentially dangerous*, but my question is not about editing. There is no point in editing the log files. I just want to see them.
danzel avatar
cn flag
@Paul Jurczak the file permissions do not allow your user to see that file. That's not a restriction by gnome or gedit. You will need root privileges to read it. There is a "logs" application preinstalled which asks for your password when opened. I don't know if it shows the contents of `/var/log/boot.log` specifically, though. I'm not aware of any text editor that asks for root permissions when _opening_ an arbitrary file.
Paul Jurczak avatar
pe flag
@danzel From a comment to my question above: *FWIW KDE's text editors (Kwrite and Kate) do allow opening files in read-only mode, and will do exactly that when you open a file you don't have write permission for.*
danzel avatar
cn flag
@Paul Jurczak that's what I wrote in my answer. **Every** text editor will happily display the file contents if it is allowed to read the file. Some (like Kate) allow you to elevate your privileges to write to the file. No application in the world is able to display a file it cannot read.
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.