On 18/09/2020 17:44, Bastien Nocera wrote:
Neither me not Till seems to be familiar with Flatpak, so I would
appreciate if provide a bit more detailed explanation of how the
things
expected to work.
This isn't so much about Flatpak, but about portals that Snap also uses
to implement sandboxing, even if the majority of Snaps don't implement
any kind of sandboxing (AFAIK).
Do you mean with this "majority of Snaps" the classic Snaps? This is a
type of Snaps which is less restricted and interacts more with the
system. Not really recommended. The full sandboxing you get with fully
restricted standard Snaps. My CUPS Snap
(https://github.com/OpenPrinting/cups-snap) is one of these and is
designed for communicating with clients (apps which print or which
configure the print environment) and Printer Applications (drivers as
IPP-printer-emulating daemon) both in fully restricted Snaps by
themselves. So one could get an all-Snap OS distribution with snapped
appplications, snapped CUPS, and snapped printer drivers. Implementation
of the needed system interfaces in snapd is currently ongoing. See the
links in my monthly news posts on https://openprinting.github.io/news/.
A portal is a D-Bus service running outside the sandbox offering
services to the sandbox application, such as file chooser, printing,
screenshots, localisation, etc. Sandboxed applications call a well-
known D-Bus service, and wait for an answer. The D-Bus service asks the
user about the resource to be shared, gives it back to the application.
The application doesn't need network access to access a remote printer,
for example, as the D-Bus service outside the sandbox is the one
contacting the printer. Ditto for files access, etc.
So communication of a flatpaked application is D-Bus only?
Does it also mean that only user applications (like LibreOffice,
Firefox, Darktable, ...) will get flatpaked? And system components (like
CUPS, network-manager, ...) will not get sandboxed in Flatpak packages?
Snap allows all-Snap OS distributions.
Till
