Portals and Sandboxes - use cases?

[Simon McVittie]

On Tue, 24 Oct 2017 at 22:55:35 -0400, Zach Villers wrote:
> I've edited a text file in a flatpak'd Gedit, I save the file, which
> saves to $HOME/.var/app/$APPID.

This would be unusual. More commonly, you'd save the file to a location
of your choice (e.g. ~/Documents) as selected via an apparently normal
GNOME or KDE File->Save As... dialog box.

The "magic" provided by the portals is that the dialog box is running
outside the sandbox and can access ~/Documents even if gedit can't.
The portal tells gedit to write to a location inside the sandbox, but
a different part of the portal infrastructure (the document portal)
redirects that write to the location you chose (e.g. in ~/Documents)
and the file ends up where you would expect.

Usually, the only files written to ~/.var/app/$APPID would be files
created behind the scenes by the app itself, without an explict
open/save operation - this typically means configuration and state,
such as preferences and saved window locations.

> I decide I need to do some last minute
> text transformations before emailing it off, and want to just run
> /usr/bin/sed in place over the file. Since I am running sed  as the same
> user, I should be able to access the app data in my home directory,
> correct?

sed and the shell where you ran it are not in a sandbox unless you
have taken special steps to sandbox them, so they can do whatever you
want: the file is just a file, and sed and the shell are just ordinary
un-sandboxed (trusted) processes with your full user privileges. They
are not restricted by gedit's sandbox.

The sandbox is one-way: it protects the non-Flatpak parts of your system
from the Flatpak-sandboxed app, and it protects Flatpak-sandboxed apps
from each other, but it does not protect Flatpak-sandboxed apps or the
data that they created from the non-Flatpak parts of your system. The
non-Flatpak parts of your system are considered to be trusted.

This is equally true for files in ~/.var/app.

> If I want send the file via an email using a webmail client,
> would I be able to authorize Gedit to attach the file to my webmail
> client?

If you browse for the file from the web browser that is showing the
webmail client, it isn't in the gedit sandbox, so it is not restricted
by gedit's sandbox and can do whatever you want it to. This is equally
true for files in ~/.var/app.

If you drag the file icon from gedit to the web browser or something,
making that work would require extra help from the portals (I don't know
whether a portal that would enable that actually exists at the moment).

> Would I also be able to copy the file to a remote host using scp from
> the remote machine?

There's no special reason why you wouldn't. It's just a file, and your
ssh login from the remote machine is non-sandboxed (trusted), unless
you have taken steps to restrict it. This is equally true for files in
~/.var/app.

> Would I also be able to authorize a back-up application to have access
> to all of my user data in sandboxed applications? How do I restore user
> data to the correct places from, say duply/duplicity?

Your user data in sandboxed applications is just a collection of files
in your home directory. Back up and restore your home directory like
you normally would, and don't exclude ~/.var from those backups.
(You might want to exclude ~/.var/app/*/cache from backups though.)

duply/duplicity aren't sandboxed unless you have taken special steps
to sandbox them.

    smcv