Questions regarding host services

[Simon McVittie]

On Thu, 18 Jan 2018 at 11:19:15 +0530, Umang Jain wrote:
> Can flatpak ensure that requested services in manifest (--talk-to) are
> available on host side?

Not really. They're provided by the OS, which is outside Flatpak's
scope. If that service isn't present then that feature won't work.

> I did a bit of learning under the hood and came across portals. They
> are "Trusted services under your session" that your sandbox is allowed
> to talk to; typically accessed by D-Bus.
> I have few more questions here:
>         * So, does the above perspective comes under this umbrella?
> Tracker as portal?

Not really. Tracker is a pre-existing service which does whatever its
API says it does; I don't think it has been audited for having any
particular security model yet, and read access to the Tracker index is
probably more or less equivalent to read access to the home directory
in terms of access to confidential/sensitive documents.

>         * Who/what determines safety of portals ? App-developer?

The developer of the portal.

>         * Will flatpak provide access to "all" available portals or
> just a subset (as per mention in the manifest).

Portals have D-Bus names matching org.freedesktop.portal.*, and Flatpak
automatically allows access to those names. It's up to the portal
implementation to make sure that API is safe.

The xdg-desktop-portal package is a collection of "core" portal services.
It delegates the actual work to a desktop-specific implementation like
xdg-desktop-portal-gtk (the reference implementation for GNOME and
other GTK+ environments) or xdg-desktop-portal-kde (a reimplementation
for KDE/Plasma).

Flatpak packages in distributions should have a soft dependency (like
Recommends in apt/dpkg) on an implementation of these "core" portals,
and distributions that support Flatpak should make sure their desktop
environments install the most appropriate implementation for the desktop
environment (most likely -kde for KDE and -gtk for everything else).

> I also came across Alex mentioning that eventually, there will
> android-like permission model. Users can (dis)allow or override the
> permission but the app might not work as expected

There are two main models for this.

Sandboxed apps are always allowed to talk to portals, which are responsible
for doing any necessary permissions checks themselves, like the pattern
encouraged in modern Android and iOS (where you get a prompt the first time
the app uses a particular API).

Sandboxed apps can also be given permissions in their manifest file that
are always applied, like the access to Tracker that you've seen, or read
access to the entire home directory, or access to direct rendering for
games and other 3D applications. These have to be set up in advance
because they can't be set up on-demand, and if they're sufficiently
"dangerous" to justify prompting the user then they should be prompted
for by software-installation UIs like GNOME Software, like the way all
permissions worked in older Android and some still do.

Over time, ideally everything will move from the second model towards
the first, although the second is still going to be necessary some of
the time.

    smcv