The Problem with Sudo and GUI Applications
About the problem with using sudo with graphical programs in Linux.
By. Jacob
Edited: 2022-01-04 08:00
There has been a lot of confusion about running GUI applications in Linux using the sudo command, in this article, I will try to clear up some of this mess.
Running graphical programs using sudo -i in Ubuntu is basically fine, in many cases; but, doing so is somewhat insecure, since it means that the entire GUI of the program, including its dependencies, will be run as root, and this increases the attack surface for malware to exploit — in worst case, malware could gain complete control over your system!. Of course, malware in Linux is fairly rare, so this is probably down to a few freak cases.
Traditionally some Linux users would recommend the use of gksudo instead, but this has been removed in recent versions of Ubuntu, and should not be used. In updated systems programs should prompt you if they need root privileges to run. Relying on gksudo is discouraged, since it has been removed, and might not work as intended in updated systems.
Why do people want to run programs as root?
Very few programs actually needs to have root access, and I would personally be hesitant to trust any program that asks for root without proper justification.
But, there are still valid reasons you might want root access.
1. When editing files not owned by yourself; in this case, you, most likely, still do not need root access, but rather you should configure permissions for the files correctly. For example, maybe you just need to add yourself to the www-data user group if you edit files in the Apache web directory.
2. When running GUI partition tools. Apparently GParted, and possibly other disk tools, still needs to run as full blown root to format hard disks. By that I mean that the whole GUI will be run as root, and not just the actions and commands that needs root access. This is outdated; modern programs should only ask for root access for specific things, and not to run the entire GUI. I think this is an ongoing process for many programs. To be almost completely safe, you could just just run Linux from a bootable USB, and then run the specific GUI tools needing root from that.
3. When running a file manager. Some directories might not be accessible without root access and browsing from a terminal is inconvenient. Afaik. Nemo's Open as root will spawn a full blown root GUI window, so you may want to avoid doing that; but then again, I am not sure you have any alternative yet. If anyone knows of a File Manager that can browse directories without its entire GUI needing root access, please let us know in the comments!
Editing files
Sometimes you might be editing system files or web server configurations; in such cases you could simply open them in Kate, which should then automatically prompt you for root access securely. The Kate GUI will not actually run as root, but instead it will try to make a copy of the file and replace the original with the copy.
Another option is to use sudoedit from a terminal. E.g.:
MyUserName@DreamMachine:~$ sudoedit /etc/hosts
Or:
MyUserName@DreamMachine:~$ sudo nano /etc/hosts
But then again, how often do you need to edit those files? Yes Copy/paste works better, but with Nano in a Terminal you can also copy and paste content. This works in Nano:
CTRL + SHIFT + C to copy.
CTRL + SHIFT + V to paste.
Running graphical (GUI) programs as root
Another problem with using plain sudo is that you are running the program as the root user (elevated privileges) inside the calling directory; this can, in worst case, change the ownership of your important files to root, and, depending on what files got changed, prevent you from booting up the system.
Note. This problem was even worse before Ubuntu 19.10, because using plain sudo would not change the $HOME directory to root's home directory. You would have to use sudo -i.
Source: How does sudo handle $HOME differently since 19.10? - askubuntu.com
Running graphical applications with root privileges is not bad in itself, and has been the norm for years. With Wayland, this seems to be disallowed by default, and applications will instead have to be updated to use polkit; the problem is that some programs has not yet been updated for that, specifically Disk Partitioning Tools, and File Managers, which probably still runs their entire GUI as root.
However, it has been, and still is, totally fair for desktop users to run the file manager (Nautilus in Ubuntu) as root when installing programs and performing system tasks, because it is usually faster and easier than typing commands in the terminal. Desktop users, in particular, prefer using GUIs, and there is nothing wrong with that. Even some system administrators prefer it at times.
What is a very serious problem, however, is the fact that Linux does not yet offer a decent GUI/desktop experience due many such silly problems that are not solved properly before migrating to new ways of doing things. But, to be fair, I actually think Microsoft has had a tendency to make even worse mistakes, such as their destruction of the Windows 11 taskbar implementation.
Using sudo -i or sudo -H
You will often see recommendations to either use sudo -i or sudo -H. For the most part, these seem to be safe, and they might even lower the risk of accidentally changing permissions of your important files.
This has the following effects:
1. Using sudo -i will spawn a child shell, specifically the one listed in the root's password database.
2. The .profile, .bash_profile and .login will also be read by the shell.
3. The shell will attempt to CD into the root's home directory, which is not done with plain sudo (evident if you run sudo su and try to login).
The problem is, if you just use plain sudo [command], you will still be located inside the calling directory. E.g.:
MyUserName@DreamMachine:~$ sudo su
[sudo] password for MyUserName:
root@DreamMachine:~$/home/MyUserName/#
Tip: The Nemo file manager has a Open as root right-click feature, which you can use instead of working with the Terminal.
You should make sure to close any applications and terminal windows with root access once you are done using them, but this is likely most relevant for system administrators, and if you are worried that someone with physical access to the system might take advantage of the situation.
The problem is also with developers of certain applications, such as Nautilus and gedit. They should include a root option out of the box. Or, distributions, such as Ubuntu, should shift to another app that includes it, since desktop users expect such basic features.
Older Ubuntu versions
Older Ubuntu versions did not change the $HOME directory to root's when using plain sudo automatically; the variable should be changed to /root to be changed correctly!
You can easily test if you are effected by this by typing the following command:
sudo sh -c 'echo $HOME'
The output should be /home (or whatever the root's home is). If not, you may use sudo -i to have the environment change properly.
Running Programs as root is insecure
I personally think this argument is irrelevant to non-developers. It assumes the code the user is running is compromised, which may be useful to developers trying to create more secure GUI applications. But, it does little to address how users and applications currently behave in the real world.
The argument is also not completely true, since running any application or code as root can be insecure. Not just GUI applications!
The worst problem is, running a GUI app as root will not just give the app itself root access, but potentially anything that runs under the X environment. This is pointed out by Martin Flöser here: Editing files as root (external link)
It is also true that GUI applications often will be larger than basic CLI applications (Programs you run in a terminal), and as such, they are harder to review for malicious code and bugs. The same can be said of very large CLI applications.
When it comes to the few GUI applications that still needs direct root access... This is likely limited to applications such as Gedit, Nautilus or GParted. Currently, it is not possible to run these in a straight-forward, secure, manner for non-technical users. In these cases, I do not really think it is useful to point users towards complicated solutions.
Inform users of the small risk, and then tell them how to do it. These programs are often run as root by users, and as far as I know, no one has reported any security problems by doing so using one of the traditional means (I.e. sudo -i).
However, according to discussions around the internet, like this one (external link), full root-access is in not necessary for GUI applications. Instead, apps should be updated to use PolicyKit or D-bus. Wayland is known to cause problems with GUIs and sudo which is still discussed by developers.
Links
- Graphical sudo - ubuntu.com
- [wayland] can't run application as root using sudo - gnome.org
- sudo with graphical apps doesn't work on wayland - redhat.com
- Graphical applications can't be run as root in wayland (e.g. gedit, beesu, gparted, nautilus) - fedoraproject.org
- Editing files as root - martin-graesslin.com
- How does sudo handle $HOME differently since 19.10? - askubuntu.com
- $HOME changed by sudo - lists.ubuntu.com
Tell us what you think:
I have a GUI application that needs to handle more advanced events from the keyboard, so using <linux/input.h> is best, but this requires root access, on cases like this what is the recommended approach? the GUI app is continuously listening to the keyboard events, so it's not a one-time operation like a file edit, how can this be approached?