[Discussion] Possibilities to add support to install / uninstall / updates Flatpak apps from another Flatpak sandbox

[haecker-felix]

I'm currently developing Souk, which is a Flatpak-only "store" frontend (https://gitlab.gnome.org/haecker-felix/souk). Souk itself gets distributed as Flatpak application.

During the development we tried to figure out, what's the best way for installing / uninstalling / updating Flatpak applications from a Flatpak sandbox. We stumbled over following ideas:

1. Bundle (lib)flatpak with the application itself, and write directly to the ostree repository.

This approach only works for writing to user installations. Writing directly to the system installation is not possible, since it need further privileges / polkit authorizations to access the system installation. Since everything defaults to system at the moment, this won't work. We don't want to limit Souk to user based stuff only.

2. Using (lib)flatpak only to read information from installations, and use Flatpak CLI for writing actions.

That's how we're currently installing / uninstalling stuff in Souk. We're calling the hostside flatpak CLI by using flatpak-spawn --host, and for reading information we're using libflatpak. This kinda works, but feels pretty hackish. When Flatpak decides to change its CLI interface, Souk will break completely.

To prevent such breakages in future, we're wondering what we could do to prevent it. As I see there's currently no proper way for solving this problem, beside installing the store application itself as non-flatpak application. Maybe we can use this issue to discuss about potential solutions for the future. For example, maybe a DBUS portal could work, which talks to the hostside flatpak?

[mwleeds]

The work in #3322 may be relevant.

[haecker-felix]

The work in #3322 may be relevant.

In theory a portal would work, unfortunately #3322 is currently limited to install only extensions of applications.

        Note that installation is only allowed if the ref is an
        extension of the application making the request or the
        runtime it is using.

[haecker-felix]

I talked a bit with @matthiasclasen on the Flatpak IRC room, and have to agree it's not realistic to make the whole API of libflatpak available per dbus / a portal.

[mwleeds]

Quoting from #4437:

I think it would be okay to mark as duplicate of #4046 so long as we are allowing support for choosing which installation (and optionally providing a path) to the installation necessary. Another possibility would be for it to install using any installation, but provide paths to additional installations to check.

So I'll close that issue and when this is implemented we can use the implementation ideas there for it, as well as the custom installation requirement.

[soredake]

Also flatpak/xdg-desktop-portal#283

[haecker-felix]

Small update - I think I have found another 3rd option. Also not completely without tricks / hacks, but I think this is by far the best method.

Libflatpak is bundled inside the Flatpak sandbox and also works inside the sandbox. To make privileged (system-wide) changes, the following changes are necessary:

• Enable --system-talk-name=org.freedesktop.PolicyKit1 so libflatpak can ask system polkit for permissions
• The actual privileged (root) operations are not performed from the sandbox, but by the Flatpak flatpak-system-helper daemon running on the host system. To communicate with it, the --system-talk-name=org.freedesktop.Flatpak.SystemHelper permission is required.
• To access the system repository (readonly), the --filesystem=/var/lib/flatpak/ permission is required (actual write access is performed via the flatpak-system-helper host daemon).

This was relatively "easy" since the actual operations on the host side are performed by the flatpak-system-helper daemon. Ironically, the user related operations were more difficult, since there is no daemon on the host side to perform the operations. The following changes were necessary:

• The installation must be created manually with flatpak_installation_new_for_path(), because flatpak_installation_new_user() would point to /home/<username>/.var/app/<appid>/data/flatpak/repo/.
• In the sandbox, flatpak-bwrap cannot be executed. This must be forwarded to the host system with the appropriate file descriptors. In Souk's example I solved this with a wrapper script (not very nice, but gets the job done). This is not strictly required, but for some apps with extra_data, e.g. Spotify, this is needed as flatpak-bwrap would be executed during installation.
• The FLATPAK_BINARY=/usr/bin/flatpak environment variable must be set, otherwise the flatpak path in the exported desktop files would be wrong.

With this method, both system and user operations can be performed from a Flatpak Sandbox, without executing Flatpak commands with flatpak-spawn --host, and parsing its output manually (idea 2 in the first message above).

CC: @chergert you may be interested in this, as far as I know Builder currently has no way to install SDKs system wide, and is limited to the user installation.

I have implemented this option as a proof-of-concept in Souk, from the tests I have done, it seems to work without problems:

Screencast_from_26-06-22_16.05.41.mp4

The code is available at: https://gitlab.gnome.org/haecker-felix/souk/-/tree/souk-next
I am open to feedback / thoughts!

[mwleeds]

To access the system repository (readonly), the --filesystem=/var/lib/flatpak/ permission is required (actual write access is performed via the flatpak-system-helper host daemon).

Wouldn't you need --filesystem=/var/lib/flatpak:ro to make the access read only?

[haecker-felix]

@mwleeds ah yes, you're right. Though I think it wouldn't even make a difference if it was explicitly stated, since the Flatpak sandbox wouldn't have write access to the directory anyway.

[soredake]

Example of the apps that needs this functinality:

1. Lutris: lutris inside flatpak needs a way to launch other flatpak'ed emulators, right now they are considering bundling ALL emulators inside Connect with installed Yuzu flatpak instead of normal Lutris runner flathub/net.lutris.Lutris#198
2. RetroDECK: retrodeck inside flatpak needs a way to launch other flatpak'ed emulators, right now retrodeck's flatpak bundles ALL emulators it can use, which is results in ~2.53 GB installed size.
3. Syncplay: if syncplay dev is ever will consider flatpak'ing syncplay, it will need a way to launch flatpak'ed mediaplayers.
4. VSCode may need it to launch unity.
5. Gimp will need to open external RAW editor.
6. Clubhouse needs it to detect if app is installed.
7. KeePassXC needs it for some functionality.
8. OpenShot needs to launch another software.

Right now this software uses/will use flatpak-spawn --host:

1. EmulationStation-DE https://gitlab.com/es-de/emulationstation-de/-/blob/ee0750d273a64d083c4557063a5485b96185d4fc/es-app/src/FileData.cpp#L1536-1538
2. Lutris flathub/net.lutris.Lutris@b429784
3. FreeCAD https://github.com/flathub/org.freecadweb.FreeCAD/blob/master/openscad.sh
4. TLPUI https://github.com/flathub/com.github.d4nj1.tlpui/blob/master/host-exec-wrapper.sh
5. Atoms https://github.com/AtomsDevs/Atoms#enable-distrobox-integration
6. Boilr https://github.com/flathub/io.github.philipk.boilr/blob/master/io.github.philipk.boilr.yml#L26

Actually there are MANY flatpak's that use flatpak-spawn --host https://github.com/search?p=1&q=org%3Aflathub+org.freedesktop.Flatpak&type=Code

[hfiguiere]

FWIW, FreeCAD abuses¹ flatpak-spawn to launch OpenSCAD as a command-line converter, and does this using the flatpak. With all the caveats, like it will fail if the flatpak isn't installed.

Footnotes

1. I did the work, I own it. ↩