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:
how to implement a confined Wayland server snap that can work on Classic; and,
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.
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?
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.)
As far as $XDG_RUNTIME_DIR goes, you really need a user session for that to make sense. Creating the directory yourself outside of a session is also a bit risky: systemd could come along and mount a tmpfs over the top.
I don’t think snap should be setting the environment variable if it is started in a context where it hasn’t already been set.
I theory I agree and a Wayland server could use “magic” to pass an FD directly to a client without using $XDG_RUNTIME_DIR.
But, in practice, FD passing is not supported by the toolkits I’ve looked at, and there’s no “magic” in the wayland interface that makes it possible to pass the FD. That left making the endpoint in $XDG_RUNTIME_DIR “work” as the agreed mechanism. (The Wayland, dconf and XDG_RUNTIME_DIR link mentioned above explains where we were before this stopped working on Classic.)
My point was more that rather than asking “why are various aspects of user sessions not available when I run my service outside of a user session?” maybe ask “how can I run my display server as part of a user session?”.
I don’t have a ready answer to that, but it might lead to a better long term solution. While it might just be XDG_RUNTIME_DIR today, tomorrow it might be access to a D-Bus session bus. I know you’re kind of forced to take the approach you have for Ubuntu Core systems, since there is no facility to bootstrap a user session there. But that’s not obviously the best option of classic systems (and perhaps not on core systems either).
I thought it was clear from the subject line that I was asking if there is any way to get mir-kiosk working on Classic again.
I don’t want to lightly abandon the approach we had working for most of last year as it balanced a number of conflicting concerns and was discussed at some length (by people that understand the way this environment is supposed to work better than I do). There’s an explanation of how this approach is now failing in case there’s a simple solution.
If it is intentional that the “various aspects” stopped working, then I’m open to another solution. Preferably one that also works on Core.
Sorry for just looking at this now @alan_g. The answer to “Can a confined Wayland server snap work on Classic systems?” is no, not today, but we can adjust snapd to allow it to work. I put a detailed comment in the bug:
Note I agree that someone should investigate creating a session for snaps that run as root, but the current workaround of allowing creation of /run/user/0 is the best we have in the immediate/short term.
I’ve implemented @jdstrand 's recommendation in : https://github.com/snapcore/snapd/pull/6525
and confirmed it allows mir-kiosk to run on my classic system, and test gui wayland snaps could run on both wayland servers (mir-kiosk and gnome)
-G
