5

Under the new Wayland display server, several applications requiring root permission fail to run. I actually have an answer (one way of working around the issue). I welcome any better solutions or criticisms.

Many other answers to this issue recommend adding root to xhost which, while it solves the issue, breaks the Wayland security model a bit. It is much better that we add root to xhost only for the duration of the running of the program, be it synaptic or gparted or whichever.

Gufw:

Edit your gufw.desktop file (/usr/share/applications/gufw.desktop in Debian 10) and change the line:

Exec=gufw

to

Exec=sh -c "xhost +si:localuser:root && gufw && xhost -si:localuser:root"

Synaptic:

Inspired by the post at: https://discourse.ubuntu.com/t/adding-applications-to-start-up/9288 Edit /usr/bin/synaptic-pkexec to comment out the zenity warning message (assuming Debian 10) and change the line:

exec "/usr/sbin/synaptic" "$@"

to

xhost +si:localuser:root
pkexec "/usr/sbin/synaptic" "$@"
xhost -si:localuser:root

I imagine other programs can mostly be adapted in the same way as gufw. This does not solve the underlying issue of old programs running everything including GUI as root but at least they can function like before.

1
  • The xhost mechanism does not work on remote desktop connections, e.g. when X2go is used to get desktop of Linux machine. I will get following error: ` kalle@kalle-linux:~$ xhost +si:localuser:root localuser:root being added to access control list xhost: must be on local machine to add or remove hosts. ` Do you have any ideas, how to get this working with remote desktop environments?
    – Kalle
    Jan 19, 2021 at 14:15

3 Answers 3

4

In Wayland, other users cannot start applications because they cannot access the Wayland socket file located at $XDG_RUNTIME_DIR/$WAYLAND_DISPLAY.  However, root ignores all file permissions and so can perfectly access the socket file when its full path is specified in WAYLAND_DISPLAY. Because of an implementation detail in the Wayland client library, it is also necessary to define XDG_RUNTIME_DIR to something (even if the actual value is not really used).

So it is actually possible to run Synaptic as a pure Wayland application with something like

sudo /bin/env WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY"  XDG_RUNTIME_DIR=/user/run/0  /usr/sbin/synaptic

So far, I tested that trick only with Sway.

4
  • It's very surprising that there is no official support for using sudo with GUI applications? I tried this command with synaptic and am getting the same error as before (it didn't work). The other comment says to enable ssh for the root use with I definitely don't want to do! Weird.
    – MRule
    Sep 21 at 7:24
  • Strictly speaking, waypipe does not require ssh. Here is a short 'sudo' script inspired from the examples in man waypipe. Damned! Ican't add a multi-lines reply? Sep 22 at 11:10
  • SOCKET="/tmp/socket-waypipe-$USER" ; waypipe --socket $SOCKET client & ; sudo env XDG_RUNTIME_DIR=/user/run/0 waypipe --socket "$SOCKET" server -- "$@" ; kill %1 ; Sep 22 at 11:12
  • Make sure that the XDG_RUNTIME_DIR for root makes sense and exists. Your's should be something like /user/run/1000 . Also, the script is not perfect since it always reuse the same socket file. Sep 22 at 11:14
1

And if ssh is enabled for root, then it is also possible to use waypipe: https://gitlab.freedesktop.org/mstoeckl/waypipe

waypipe ssh root@localhost synaptic
0

Here is a shell script to run any Wayland program as root using sudo and waypipe (no ssh needed). This is inspired from the examples in the waypipe man page.

sudo does not start a proper user session. That can be problematic for some applications. See the comment for more details.

#!/bin/bash

# There is still a small risk of collision when using -u but this is unlikely.
SOCKET=`mktemp -u /tmp/sudo-waypipe.XXXXXXX.sock`

waypipe --socket "$SOCKET" client &

# waypipe --server requires a proper XDG_RUNTIME_DIR directory for the root user.
#
# That should typically be /run/user/0 or /var/run/0
#
# Unfortunalely, sudo does not create a user session so this variable is not set.
# Even worse, systemd destroys the directory when the last session terminates.
#
# In practice, that means that we cannot assume that /run/user/0 or /var/run/0
# exists and, even if it does exist, it cannot be safely used because it may
# be removed by systemd at any time. 
#
# Ideally, a user session should be created for user 0 (via systemctl?) 
# but this is not that easy. The alternative is to use a custom directory in /root
#
# The disadvantage is that the application may not be able to access services
# such as dbus.
#

sudo sh -c "XDG_RUNTIME_DIR=\$HOME/xdg-run/ ; mkdir -m 700 -p \$XDG_RUNTIME_DIR ; export XDG_RUNTIME_DIR ; waypipe --socket $SOCKET server -- $(printf "%q " "$@")"
kill %1
rm -f "$SOCKET" 

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.