4

On the X desktop, I ocassionally used gksudo or just sudo somegui to launch GUI applications as another user, including root. I recently discovered that this is not possible on contemporary (early 2018) Wayland desktops. All applications must launch as the current desktop user, and are limited to the privileges of that user.

Is this a permanent feature of Wayland (there by design), or is su-type usage an enhancement that has not yet been implemented?

I'm looking for a documented statement (roadmap, design page...), not preference or opinion.

8

Is this a permanent feature of Wayland (there by design)

No. This has nothing to do with the wayland protocol. It is rather a question of environment setup.

Wayland uses a socket, its name is stored in WAYLAND_DISPLAY. It is located in XDG_RUNTIME_DIR that is normally set up for user access only. But root can access it, too. (Some applications also regard XDG_SESSION_TYPE which can have values wayland or x11 to decide whether to use X or Wayland.)

sudo deletes most environment variables including XDG_RUNTIME_DIR and WAYLAND_DISPLAY.

You can run wayland applications as root with:

sudo env XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR WAYLAND_SOCKET=$WAYLAND_SOCKET waylandapplication

or shorter with -EH to preserve almost all environment variables (but setting HOME to /root). This will include DISPLAY and XAUTHORITY for Xwayland access, too:

sudo -EH application

Though, if the application running as root writes anything in XDG_RUNTIME_DIR, it can cause file permission issues for user applications.

However, running graphical applications as root in wayland is much less a security issue than it is in X11.

To avoid using X11 accidently, you can run without DISPLAY:

sudo -EH env DISPLAY=  waylandapplication

I'm looking for a documented statement (roadmap, design page...), not preference or opinion.

The Wayland documentation mentions WAYLAND_DISPLAY, but I do not find anything about XDG_RUNTIME_DIR. Though, all wayland compositors including the reference implementation weston depend on XDG_RUNTIME_DIR.

If WAYLAND_DISPLAY would be at another location, it would not be a problem to run applications from arbitrary users on the same wayland display. But XDG_RUNTIME_DIR ist specified to be restricted on the logged-in user and should contain user related sockets:

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

The issues with running another user or root on wayland are rather related to the XDG_RUNTIME_DIR specification than to wayland itself. If you specify a custom XDG_RUNTIME_DIR in /tmp with arbitrary access (thus breaking its specification), all users can use the wayland display.

There is some hope for the future not to need XDG_RUNTIME_DIR, but it depends on the implementation: Wayland docu chap.4:

Beginning in Wayland 1.15, implementations can optionally support server socket endpoints located at arbitrary locations in the filesystem by setting WAYLAND_DISPLAY to the absolute path at which the server endpoint listens.

| improve this answer | |
  • 1
    sudo -EH to keep environment but reset HOME? – muru Feb 11 '18 at 0:45
  • @muru thanks, I've added your suggestion to the answer. I was not aware of -H. – mviereck Feb 11 '18 at 1:27
  • sudo -EH env DISPLAY= waylandapplication works to launch apps as root, but sudo -u normal_user -EH env DISPLAY= waylandapplication fails to launch the app under a non-root user. – Maximko Jan 4 at 4:04
0

Although I'm not answering your question directly, I think there are people who may have ended up here because of the same problem.

This is a script that I have made is a workaround for people who need to run graphical application (like Gedit, Synaptic or GParted) as root via sudo in a Wayland session:

https://gist.github.com/wachambo/bd22e12db2d5a46dc109bd0d553733be

Imported here:

#!/usr/bin/env bash

#
# Enable root access to x-windows system.
#
# Motivation: Trying to run a graphical application as root via su, sudo in a 
# Wayland session (e.g. GParted or Gedit), will fail. Apps which use polkit to
# request administrator permissions for just certain operations and only when 
# needed are not affected (they are not started as root right away). 
# [1] https://bugzilla.redhat.com/show_bug.cgi?id=1274451
#
# Based on a Reddit comment.
# [2] https://www.reddit.com/r/Fedora/comments/5eb633/solution_running_graphical_app_with_sudo_in/

if (( $# != 1 )); then
    echo "Illegal number of parameters."
    echo
    echo "Usage: wsudo [command]"
    exit 1
fi

for cmd in sudo xhost; do
    if ! type -P $cmd &>/dev/null; then
        echo "$cmd it's not installed. Aborting." >&2
        exit 1
    fi
done

xhost +SI:localuser:root
sudo $1
#disable root access after application terminates
xhost -SI:localuser:root
#print access status to allow verification that root access was removed
xhost
| improve this answer | |
  • this is great, but I think better posed as a separate Q&A, with a link to this question, it will then come up as a related question - I'm also happy to link to the new question – lofidevops Oct 10 '18 at 6:01
  • This is a great hint, but it does not work on SSH connections - only on the local console. – Kalle Jan 28 at 11:42
  • @Kalle With ssh X forwarding you can just run the command - in fact you can run them "locally" too by ssh'ing to the root user; i.e. ssh -Y root@::. – Thomas Guyot-Sionnest Jul 3 at 6:39
  • Sorry, but it is out of question to enable ssh:ing into system as root user. This is for security reasons - commands executed throuh sudo can be limited, and they leave a trace on logs. – Kalle Jul 4 at 13:48
0

There are two fairly easy workarounds. The examples below start synaptic but any other command should do.

  1. Using ssh X-Forwarding to the root user (you may have to enable root login in /etc/ssh/sshd_config or configure key auth):
$ ssh -Y root@:: synaptic
  1. Using socat & sudo, as proposed by bober on RedHat Bug #1274451. The example below assumes we're on display #0 and #1 is free...
socat UNIX-LISTEN:/tmp/.X11-unix/X1 UNIX-CONNECT:/tmp/.X11-unix/X0 & sudo DISPLAY=:1 synaptic

I believe either way the workaround is to have a user-owned process to connect to X11 socket and provide tunneling .

| improve this answer | |

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.