Miriway is a (Wayland/Mir based) desktop environment.
Desktop environments need to launch applications, including non-snap applications. And are a category for which classic confinement may be granted.
category: shells (which includes desktop environments)
Hello @alan_g, I think a desktop environment is broader than a shell. @pedronis , what is your thought about this?
I don’t want to start a digression into the difference between shells and desktop environments, but there are shells which are not desktop environments (e.g. command-line shells).
In any case, Miriway is a graphical shell with window management, a launcher, a background and a status bar. (Sorry if calling that a desktop environment is causing dissonance)
The category is “terminal emulators, multiplexers and shells”, my understanding is that shells there means command-line shells.
I understand the way graphical shells are similar and different to those. But the main difference is one of audiences. So probably graphical shells need their own separate discussion.
OK, where should we discuss this?
@pedronis What can we do in this case? Maybe add a “graphical shells” category for classic snaps?
There is prior art for approving classic confinement for desktop environment snaps. Here is a very similar case:
I was not involved with that decision, I notice that that snap never made past edge.
Regarding the general topic, we have been discussing to do a more general review of the policies for classic to clarify some things and cover some situations that are not part of the current list.
My input about “graphical shells” is that the on top of the usual requirements for classic, it seems they would need to be published by the project upstream directly, otherwise there is too much risk of change of directions and frictions that is not compatible with being shipped as a snap.
Let me chime in here. Miriway is a bit special as it’s not a self-contained shell in a snap. It’s more of a shell developer environment - you configure it to pick up pieces from elsewhere as shell components (e.g. panels, launchers etc.). When happy with a setup, you can snap it all up as a confined desktop environment, and that’s what’s we did here:
But Miriway itself needs to be confinedclassic so it’s possible to bring the shell components in from outside the snap.
Following on from @Saviq’s chiming in I think I need to add some details to ensure any further discussion isn’t confused.
There are multiple things in this snap, some of which don’t need classic confinement, some of which do.
| Part | Description | Needs classic |
|---|---|---|
| miriway-shell | Graphical shell | No |
| waybar | Shell panel | No |
| swaybg | Background | No (but does need access to any chosen wallpaper) |
| miriway-terminal | Terminal emulator | Yes, and “terminal emulators” is in a “known categories” |
| xwayland | X11 server | Yes, not a “known categories” |
| wofi | Application launcher | Yes (to run arbitrary applications), not a “known categories” |
The confined-shell mentioned above achieves a subset of this:
| Part | Description | Needs classic |
|---|---|---|
| miriway-shell | Graphical shell | No |
| yambar | Shell panel | No |
| swaybg | Background | No (snap includes ubuntu-wallpapers) |
| wofi | Application launcher | No, uses desktop-launch to run snaps (only) |
This is only true if all the apps you want to run are both snapped and Wayland based.
I can imagine we could separate out Xwayland, the launcher and the terminal emulator into a “helper” snap with classic confinement, and invoke those from a confined shell to get the same result. However, before starting on that work it would be good to have an assurance that this “helper” snap could be granted classic confinement.
Hello Alan,
Our preference would be to see this snap separated. The requirements for classic are well understood, so if the separation is completed classic will be granted. Is that something that is possible in a reasonable time frame?
It can be done, but raises a question: how to “tie” the snaps together. E.g.
-
Should the classic part be the principle install, and install the confined part in the
installhook? 1.1. If so, should the confined part be uninstalled in theremovehook? (What if there were another user?) -
Should the confined part be a “default provider” of some (arbitrary) snap interface
In my opinion this would get unwieldy pretty quickly.
Some shell components will require access to privileged Wayland interfaces. We have no way to safely identify privileged clients to give them this access if we’re not in control of them and they’re unconfined (and so, can impersonate others).
1 Like
Yes, you are right: it is going to be fragile:
Launching the components via the desktop-launch interface would simply be messy (cluttering /var/lib/snapd/desktop/applications/ with a desktop file for each shell component and “magically” providing those names to the confined snap).
However, there’s no reliable way to identify these apps once they are launched by userd. I was thinking we could use the apparmour id, but they wouldn’t be confined, so that doesn’t work.
@dclane, having thought about it some more, I wish I’d never mentioned the possibility of splitting the snap into “classic” and “confined” parts.
There are trade-offs, and splitting the snap content doesn’t help.
The Wayland compositor (the bit that is a candidate for “confined”) needs to know which processes can be trusted to provide parts of the desktop (panels, x-server, launchers, wallpaper, …). Where processes can be launched directly by the compositor it is possible to track their pid (this is what Miriway does now) and, as they are direct clients, this works well enough.
However, some of these components (those that launch apps, or serve X11) need to be “classic”. And launching them via desktop-launch means, in essence, that the compositor needs to trust any connecting process to provide parts of the desktop (not just ones from the classic snap).
There are some additional problems providing the environment needed to start Xwayland that I don’t see a way to resolve. (E.g. the compositor needs to create the X11 socket and identify the FD as a command-line option.)
This is, of course, “all software” and it would be possible to move large chunks of the compositor into a process in the classic snap, but this would then need a rich communication channel to interact with the part that remains confined. I think this is beyond a feasible amount of work.