4

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.

5
  • 3
    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.
    – David Z
    Nov 12, 2022 at 17:26
  • 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). Nov 13, 2022 at 2:04
  • 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.
    – David Z
    Nov 13, 2022 at 6:32
  • 1
    @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. Nov 13, 2022 at 18:19
  • @DavidZ I just installed Kate on Mint 21 and it doesn't allow to open /var/log/boot* files, just like gedit. Nov 13, 2022 at 20:49

4 Answers 4

11

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
5
  • 1
    This is more cumbersome than just sudo gedit. Nov 12, 2022 at 0:00
  • 8
    @PaulJurczak what is your criterion for an acceptable level of effort? Nov 12, 2022 at 0:04
  • @OrganicMarble The same user input as for user files + entering root password. Nov 12, 2022 at 1:00
  • @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.
    – Bakuriu
    Nov 12, 2022 at 14:52
  • 2
    +1, but I'm curious where this recommendation comes from. I guess it's some gvfs magic, but a documentation link would be nice.
    – danzel
    Nov 12, 2022 at 20:10
8

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.

1
  • 1
    Your other answer was more direct (recommended way), but I'm choosing this one as more practical (convenient way). Thank you. Nov 12, 2022 at 18:10
4

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

2

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.

8
  • It is best to not open graphical applications using sudo. See Why should users never use normal sudo to start graphical applications? for more information.
    – Enterprise
    Nov 12, 2022 at 12:54
  • 1
    @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?
    – terdon
    Nov 12, 2022 at 14:04
  • @terdon, thanks for the link. I think there is still some (perhaps minor?) concern... "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.
    – Enterprise
    Nov 12, 2022 at 14:30
  • 1
    @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.
    – terdon
    Nov 12, 2022 at 14:38
  • 1
    @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.
    – danzel
    Nov 12, 2022 at 20:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .