segfault authored Jan 04, 2021 and intrigeri committed Oct 12, 2022

Split the Persistent Storage app (formerly known as
tails-persistence-setup) into a backend and a frontend, both written in
Python. The frontend communicates with the backend via a D-Bus service.

New features:

* Support for activating Persistent Storage immediately, without
  rebooting (refs: #11529)

* Support for activating features selectively

* Support for mounting files

  live-boot only supported mounting directories, but it's actually useful
  to also be able to mount single files.

* Correctly handle error condition for feature activation with symlinks

  If a feature using symlinks is activated but the source directory is
  empty, an error is now returned, because there are no files which
  symlinks could be created for.

Otherwise, since /live/persistence/TailsData_unlocked is not readable by the
amnesia user anymore, navigating into the Dotfiles source directory from the
Files browser becomes overly difficult.

refs #7465

We stopped supporting read-only persistence years ago, but there's still some
leftover code here and there. Let's remove it.

refs #17972

Currently translated at 17.7% (11 of 62 strings)

Translation: Tails/wiki/src/news/version_3.14.1.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_3141po/pt/

Currently translated at 39.0% (16 of 41 strings)

Translation: Tails/wiki/src/news/version_3.11.*.po
Translate-URL: http://translate.tails.boum.org/projects/tails/wikisrcnewsversion_311po/it/

Will-fix: #16629

Will-fix: #16629

In my tests, these launchers are clickable and work as intended
even without this call. I suspect touch'ing them was needed
for the xdg/autostart implementation but is not needed here.

Somewhen @metadata::trusted yes@ whas the right thing to do, but nowadays
you have to use @metadata::trusted true@. What was taking me one day to
spot. The internet has still a lot reference to @metadata::trusted yes@.

I added also Requires and After to the service file, to make sure
systemd starts gvfs-metadata deamon before ours. We need this DBus
interface to be availabe to get gio working.

The ConditionUser= directive was added in systemd v234, that's not in Stretch.

... like we do in most places. This makes these highly relevant
properties of the scripts a bit more easy to spot.

This is merely preparatory work that lays down some foundations.

For now, we're using two targets:

 * basic.target sets up things that should be done as early as possible, don't
   need access to X, notifications, nor D-Bus ; it is automatically started by
   `systemd --user' when the logind session is created. Note that this happens
   after persistence has been set up, when the GDM autologin is triggered, and
   before /etc/gdm3/Xsession is run:

   - tails-add-GNOME-bookmarks.service
   - tails-create-tor-browser-directories.service

 * desktop.target: we're starting it via xdg/autostart during the GNOME session
   startup. There are a few units wanted by this target so far:

   - tails-configure-keyboard.service

   - tails-virt-notify-user: ideally, this should have something like
     After=notifications-ready.target (and then, most other things that
     wait for GNOME Shell to be ready to handle notifications could do the
     same instead of grep'ing the process list).

   - tails-warn-about-disabled-persistence.service

   - tails-upgrade-frontend.service: the idea is to later use systemd units
     ordering to make it run at a time that increases chances for the system
     having enough free memory; e.g. as soon as possible once the session is
     ready, Tor has bootstrapped, and some other memory-hungry programs we run
     at session startup time have completed.

   - tails-security-check.service: similarly, the idea is that we could get
     rid of the wrapper — that merely waits for Tor to have finished
     bootstrapping — given another systemd unit.

Most of these units exit early unless they're run by the `amnesia' user.
Otherwise they break e.g. Tails Greeter startup, and probably worse.

Also note that the units that may take ages to complete have Type=simple.
With Type=oneshot, systemd would wait for them to complete before running any
follow-up units, and before considering the target they're part of has been
reached. Two of our units can take minutes to complete, so the desktop.target
startup would fail. Now, using Type=simple has one drawback: it makes it harder
to order other units relatively to tails-security-check-wrapper's and
tails-upgrade-frontend-wrapper's completion. This doesn't feel too bothering,
though: it's more likely that we want to configure these units to start after
others, than the opposite.

Also, when the GNOME session is initialized, we import the relevant D-Bus, X11
and locales variables into systemd --user's environment, so that our units can
use them. We do that immediately before starting desktop.target.

WIP: Rename the Tor Browser "download" directory, again. And add automated tests for the Tor Browser.

The idea is to make sure that the AppArmor confinement doesn't break too much
functionality, and actually confines the browser a bit.

Sorry for the non-atomic commit: getting directory name changing under my feet
while the automated tests are being drafted made it too hard to split this in
a nice way.

That is:

  * always create ~/Tor Browser files/ and a GNOME bookmark to it
  * when `~/Persistent/` is persistent read-write, create `~/Persistent/Tor
    Browser files`, and add a GNOME bookmark to it

Note that we need to URL-encode spaces when adding GNOME bookmarks.

That's not something that we expect users to need.