Bug#880601: gdm fails to give wayland an Xauthority file, preventing running applications as root

[Simon McVittie]

On Thu, 02 Nov 2017 at 13:56:34 -0400, Phil Susi wrote:
> The man page for gdm3 states that it will create an XAUTHORITY file in
> /var/run/gdm3 and set the environment variable to point to it.  It does
> not do this when running wayland.  Instead it leaves Xwayland configured
> to allow connections only from local processes running as the same user
> ID.  This prevents you from being able to run X applications as root,
> such as gparted or synaptic.

Wayland is designed to be per-uid. If you want X11, I would suggest
using X11.

Running GUIs as root gives them a huge attack surface, breaking the
privilege separation between root and the user that owns the display.
It has historically worked, but that doesn't make it a good idea for the
future (or the present, for that matter). The move from X11 to Wayland,
at which traditional approaches to various things (e.g. screenshots) break
anyway due to Wayland having the concept of privileged and unprivileged
clients, is a convenient flag-day to move from "discouraged but still
works" to "a line has been drawn here, this no longer works".

A much safer design is for an unprivileged GUI running as the user to
submit requests to a privileged service (for example GNOME Software
running as the user and submitting requests to PackageKit via D-Bus,
GNOME Disks submitting requests to udisks2 via D-Bus, and printing GUIs
submitting requests to CUPS via IPP/HTTP), and having the privileged
service make access-control policy decisions about those requests
(for example PackageKit, udisks2 and many other privileged services
authenticate the user using D-Bus' credentials-passing and delegate the
authorization decision to polkit, while CUPS authenticates the user with
a password and carries out its own authorization check for membership
of the lpadmin group).

> It also means that two users on two
> different terminals using a shared/guest UID can interfere with one
> another's X session, making it a security issue as well.

Two users sharing a uid can interfere with each other's files and
processes in numerous ways. Unix kernels are not designed to put a
boundary between different processes of the same uid, and I would
strongly recommend not attempting to do so.

Regards,
    smcv