Following on from the work done with using mir-kiosk with graphical client snaps I’ve been exploring the possibility of running a more capable shell (specifically egmde) as a snap. There are two areas where I don’t see how to proceed.
Finding other snaps
Currently egmde identifies applications by searching well known locations on the filesystem for .desktop files. That is also possible as a “classic” snap, but leads to problems for a confined snap.
What is needed is a way to identify those snaps that are consuming the “wayland-socket-dir” content interface published by the snap. I don’t see a way to do this?
Running other snaps
Currently egmde parses the .desktop files to allow the user to select an app and then exec()s the program selected. Even if (as discussed above) this were possible from a confined snap, it is unlikely that the command(s) found there would succeed.
So, following on from the above question about finding snaps that are consuming the content interface published by the snap, what options could there be for running those snaps?
i think the only proper way would be to ship a complete desktop session (a shell/WM plus a set of selected apps) and adjust all search paths properly to point to $SNAP/$SNAP_DATA/$SNAP_USER_DATA
A confined snap directly launching a different confined snap is not supported by design since the sandbox correctly blocks this on many fronts (this has been discussed elsewhere).
What is needed at a high-level are two things:
an interface that allows the snap to (ultimately) talk to an out of process helper
an out-of-process helper that will launch the application on behalf of the requesting snap if the requesting snap is allowed to do so
This needs to be designed and could be implemented in many ways, but one such implementation would be for snapd userd to expose a DBus api to launch the requested application (which is mediated by the new interface). Another is the ‘application://’ approach suggested by @Saviq where the launcher needs to verify if the calling snap is allowed to launch the ‘application://’. There are certainly others.
Yes, I wasn’t expecting this to be possible (or reasonable).
I realise we’re now talking hypothetically, but does it make sense for this same helper to assist in the identification of snaps that are consuming the “wayland-socket-dir” content interface? Or is another approach required for that?
IME, the interface would need to support enumerating the applications that could be launched. This interface is probably named ‘desktop-shell-support’ (or similar) and would include anything that is reasonable that a desktop shell would need to launch applications. To me, that sounds like more of a function of working with /var/lib/snapd/desktop/applications/*.desktop rather than anything related to the wayland socket dir, but maybe I’m missing something. Can you describe why you need something other than read access on /var/lib/snapd/desktop/applications/{,*} (and /usr/share/applications if this is ever for classic distro) for enumerating applications?
Completely disagree, there’s plenty of scenarios where you should be able to install additional graphical applications in an otherwise confined environment.
Think a smart fridge backed by a brand store. Wouldn’t you want to be able to install a selection of apps from the store? As a manufacturer, wouldn’t you like to be able to present the user with a choice of those?
