Why don't gksu/gksudo or launching a graphical application with sudo work with Wayland?
Note this answer is specific to versions of Ubuntu using Wayland, 17.10 being the first release to use Wayland by default.
It is a feature not a bug! It is a design feature of Wayland that you can not start graphical applications as root from the terminal.
The main discussions are of course on the Fedora sites. See Fedora bug #1274451 and Graphical applications can't be run as root in wayland (e.g. gedit, beesu, gparted, nautilus) on Ask Fedora. But there is some discussion on the Ubuntu sites as well (Ubuntu Devs Uncertain about Using Wayland by Default in 17.10 - OMG! Ubuntu).
Ubuntu bug report: Unable to launch pkexec'ed applications on Wayland session
Potential work around - If you are editing system files with a graphical editor (such as gedit) use a command line tool such as nano
or vim
or emacs
. nano
is typically easier for new users, vim
is more powerful and has more features, see this Vim Tutorial or similar.
At any rate , if you really want or need to run graphical apps as root, set xhost
first which forces fallback to Xserver.
To set permissions run:
xhost si:localuser:root
When you are finished, to remove permissions
xhost -si:localuser:root
You can add a graphical / desktop option to do this as per this synaptic bug report
pkexec'ed applications may be healed with
xhost +si:localuser:root
placed in XDG autostart as follows (N0rbert's idea):cat <<EOF | sudo tee /etc/xdg/autostart/xhost.desktop [Desktop Entry] Name=xhost Comment=Fix graphical root applications Exec="xhost +si:localuser:root" Terminal=false Type=Application EOF
You could add this xhost command to .bashrc, but I would advise a pair of aliases
alias gsuon='xhost si:localuser:root'
alias gsuoff='xhost -si:localuser:root'
You can name the aliases whatever you wish.
For details see:
- https://bugs.launchpad.net/ubuntu/+source/backintime/+bug/1713313
- https://bugs.launchpad.net/ubuntu/+source/nmap/+bug/1713311
- Arch Wiki: Running X apps as root
- Arch Wiki: Xhost
- What are xhost and xhost +si?
Switch back to Xorg
If you prefer Xorg for any reason, you can select to run on Xorg at login
See How do you switch from Wayland back to Xorg in Ubuntu 17.10?
Solutions
In Wayland it is often difficult to run GUI application programs with elevated (sudo -H, gksu ...) permissions. It is a good idea to do such tasks with command line tools.
But there are workarounds, if you have a GUI tool, that works well for you and needs elevated permissions. (I use two such standard tools: the Synaptic Package Manager, synaptic
and the partitioning tool Gparted, gparted
. I use MakeUSB to create USB boot drives, mkusb
, too, but it can run the parts that need elevated permissions without graphics.)
gvfs admin backend
The gvfs admin backend is a good tool for elevated permissions with GUI tools. In Ubuntu 17.10 (gvfs >= 1.29.4) and newer versions you can use the gvfs admin backend. Notice that you need the full path, for example
thunar admin:///path/to/directory
gedit admin:///path/to/file
In theory, the gvfs admin backend method (which uses polkit) is better and safer (than xhost
and sudo -H
), regardless of the UI you use.
You don't run the whole application as root. Privilege escalation happens only when strictly necessary. See the following link and links from it,
-
sisco311's reply in the Ubuntu Forums thread 'Which best practice for using gedit as root?'
This is post #4. See also post #6 in the same thread.
xhost
and sudo -H
-
There is a workaround to allow graphical application programs owned by other users than the logged in user in Wayland,
xhost +si:localuser:root
-
gksu
andgksudo
are not bundled with standard Ubuntu and do not work here, but they work in Xorg.Instead you can use
sudo -H
Edit:
-H is no longer necessary (in 20.04 LTS and newer versions)
Prior to 20.04 (or maybe 19.10, I can't remember when) using sudo for a GUI application, particularly the file manager, could change ownership of files and folders in your home to root, completely removing your ability to login to the system as user. Changes to the way the system uses sudo means that the danger of that happening has now gone so it should be safe as far as that problem is concerned.
end of edit
-
It is a good idea to prevent graphical application programs owned by other users than the logged in user afterwards,
xhost -si:localuser:root
nautilus-admin
It is also possible to use nautilus-admin
for file operations with elevated permissions and to use gedit
with elevated permissions. This is described in the following AskUbuntu answer,
- How do I start Nautilus as root?
Temporary access for root to the Wayland desktop via function gks
Please avoid sudo GUI-program
. It can cause the system to overwrite the configuration files for your regular user ID with root
's configuration and set ownership and permissions to fit root
and lock out your regular user ID. You should run GUI applications with sudo -H
, which writes the configuration files in root
's home directory /root
. Example:
sudo -H gedit myfile.txt
But there is a risk that you forget -H
. Instead you can create a function, for example gks
gks () { xhost +si:localuser:root; sudo -H "$@"; xhost -si:localuser:root; }
and store it in your ~/.bashrc
near the aliases. Then you can run
gks gedit myfile.txt
in a way similar to how you used gksudo
before.
Testing
You can check how sudo
, sudo -H
and gks
work with the following commands
sudodus@xenial32 ~ $ sudo bash -c "echo ~"
/home/sudodus
sudodus@xenial32 ~ $ sudo -H bash -c "echo ~"
/root
sudodus@xenial32 ~ $ gks () { xhost +si:localuser:root; sudo -H "$@"; xhost -si:localuser:root; }
sudodus@xenial32 ~ $ gks bash -c "echo ~"
localuser:root being added to access control list
/root
localuser:root being removed from access control list
sudodus@xenial32 ~ $
and of course
gks gedit myfile.txt
according to the example in the previous section.
Method that works via Alt-F2 and Gnome Shell menu
Instead of adding a simple one-line function to ~/.bashrc
, you can make a system, that works also without bash. It may be convenient to use, but is more complicated to set up. Please notice that you should install only one of the alternatives, because the one-line function will disturb using this more complicated system.
Three files
The shellscript gks
:
#!/bin/bash
xhost +si:localuser:root
if [ $# -eq 0 ]
then
xterm -T "gks console - enter command and password" \
-fa default -fs 14 -geometry 60x4 \
-e bash -c 'echo "gks lets you run command lines with GUI programs
with temporary elevated permissions in Wayland."; \
read -p "Enter command: " cmd; \
cmdfile=$(mktemp); echo "$cmd" > "$cmdfile"; \
sudo -H bash "$cmdfile"; rm "$cmdfile"'
else
xterm -T "gks console - enter password" -fa default -fs 14 -geometry 60x4 -e sudo -H "$@"
fi
xhost -si:localuser:root;
The desktop file gks.desktop
:
[Desktop Entry]
Version=1.0
Categories=Application;System;
Type=Application
Name=gks
Description=Run program with temporary elevated permissions in Wayland
Comment=Run program with temporary elevated permissions in Wayland
Exec=gks %f
Icon=/usr/share/icons/gks.svg
Terminal=false
StartupNotify=false
GenericName[en_US.UTF-8]=Run program with temporary elevated permissions in Wayland
The icon file gks.svg
looks like this:
You can download the icon file or a tarball with all three files from this link,
wiki.ubuntu.com/Wayland/gks
Copy the [extracted or copied & pasted] files to the following locations,
sudo cp gks /usr/bin
sudo cp gks.desktop /usr/share/applications/
sudo cp gks.svg /usr/share/icons
Logout/login or reboot, and there should be a working desktop icon. It will work from a terminal window like with the simple solution with the function.
Alt F2 box:
Gnome Shell menu:
gks console and gparted:
Custom script and desktop file
If you have only a few GUI applications, that need elevated permissions, you could make custom scripts and desktop files for them and avoid entering the command (application name). You would only enter the password, which is not more difficult compared to the previous versions of Ubuntu (you should enter the password anyway).
Example with the simple GUI program xlogo
that comes with the program package x11-apps
:
The shellscript gkslogo
(simplified compared to gks
),
#!/bin/bash
xhost +si:localuser:root
xterm -T "gks console - enter password" -fa default -fs 14 -geometry 60x4 -e sudo -H xlogo
xhost -si:localuser:root;
The desktop file gkslogo.desktop
:
[Desktop Entry]
Version=1.0
Categories=Application;System;
Type=Application
Name=gkslogo
Description=Run program with temporary elevated permissions in Wayland
Comment=Run program with temporary elevated permissions in Wayland
Exec=gkslogo
Icon=/usr/share/icons/gks.svg
Terminal=false
StartupNotify=false
GenericName[en_US.UTF-8]=Run program with temporary elevated permissions in Wayland
I was lazy and used the same icon file gks.svg
Copy the [copied & pasted] files to the following locations,
sudo cp gkslogo /usr/bin
sudo cp gkslogo.desktop /usr/share/applications/
gks[logo] console and xlogo:
Better check whether wayland is really running first before granting root right
if [ $XDG_SESSION_TYPE = "wayland" ]; then
xhost +si:localuser:root
fi
If you are using Ubuntu 17.04 or higher, it is recommended to use the gvfs admin backend. Simply add admin:// to the front of the full filepath you want to open in an app like the Text Editor or the Files apps.
For instance, to change boot settings, open
admin:///etc/default/grub
This method uses PolicyKit and will still work with Ubuntu 17.10's Wayland default, while sudo and gksu for GUI apps won't.