Can a confined Wayland server snap work on Classic systems? (And also Core systems?)


#1

The mir-kiosk snap is a confined Wayland server and used to work on both Core and Classic systems. However, towards the end of last year changes were made to the snap support on Classic that prevent it working.

You might wonder “why run mir-kiosk on Classic?” but, empirically, about half the installs are on Classic systems (not all of them Ubuntu). These only work on Classic systems because there is a “work-around”: installing the mir-kiosk snap with --devmode but that is hardly satisfactory.

  • The first symptom is that Wayland compositors need to offer an endpoint in $XDG_RUNTIME_DIR - and on Classic that directory does not exists, cannot be created in the snap and, if created “by an outside force” cannot be used. Running with --devmode suppresses this symptom.

  • If that were solved, then consumers of the Wayland interface need to be able to find that endpoint (or a link that behaves like it) in their own $XDG_RUNTIME_DIR. The way things are currently working on Core (and used to work on Classic) isn’t “obviously correct” either: both server and client snaps mess with $XDG_RUNTIME_DIR so that the endpoint can be shared.

Clearly, there are now differences in the way the wayland interface works between Core and Classic systems but it is not clear:

  1. how to implement a confined Wayland server snap that can work on Classic; and,
  2. whether there is an approach that works on both Core and Classic.

Is there an approach, or plan, that allows confined servers on Classic to create a Wayland that can be accessed by confined clients?

Or is the wayland interface not intended to be usable for this scenario? Much of the discussion I see (e.g. The desktop interfaces) appears to assume that it is for accessing a Wayland compositor provided by the system.

Notes:


#2

At least part of the problem is that the wayland interface slot is implicit on Classic, so it’s only the system that can legally provide it. To that end, the slot side AppArmor and SecComp policies only apply on Core systems.

@jdstrand I know you had some thoughts on this topic, did you write down somewhere what work you think needs doing to get this sorted out?


#3

I should also mention Wayland, dconf and XDG_RUNTIME_DIR as that details some of the history. (Although at that time snaps could create /run/user/$(id -u) and use it.)


#4

There’s an open bug on this: https://bugs.launchpad.net/snapd/+bug/1792362