tps-frontend: consider adding UI for adding custom persistent features
10 years ago we rejected this in #5383 (closed) as part of a large security push for the persistence implementation in Tails 0.21. Other than that it is unclear to me why we do not allow this, although I've seen it explicitly mentioned without explanation, e.g. in #17803 (closed) there is: "This would be consistent with the fact we don't support adding [custom persistence features] from the UI".
So, are there good reasons for us not to do this now? After all, we can't anticipate all user needs on this front, and even if we could it would be impractical to include many more persistence features than we already do. I guess the most compelling one for me is that the average user wouldn't be able to identify which folder stores the settings/data/cache for their favorite application. But I still see value for it as an advanced feature we don't promote heavily.
Design/implementation considerations:
- The implementation should be using a file chooser
- What if the target is not a folder?
- If
tpsd
supports persisting regular files (the oldlive-boot
persistence system did not) I guess we don't have to do extra work to disallow it - Symlinks? Dereferencing seems like a bad idea, probably we just remove it and replace it with an empty folder (or file if we support that per the previous point).
- If
- What about overlapping targets, when the chosen target is the same as another persistence feature's target, or one is contained in the other?
- While the old persistence feature didn't require the
source=
optiontpsd
does, but maybe we can make it as simple as: when making$PATH
persistent, we add this line topersistence.conf
:$PATH source=custom/$PATH
which actually is what the old persistence system did whensource=
was omitted (but without thecustom/
-prefix). Overlapping targets need some handling here. Another option is:$PATH source=$(uuidgen $PATH)
. - Maybe we want a blacklist for problematic targets, e.g.
$HOME/.conf
: "too general", and similar? - Maybe we should limit the file chooser to pick targets within
$HOME
? Otherwise we have to deal with problems like:- What about problematic targets like
/
,/dev
,/etc
,/home
? It would significantly increase the balcklist, as proposed above. - What about permission issues for paths outside of
$HOME
vs the file chooser? Can a privileged file chooser "remain in"tps-frontend
after it drops privileges?
- What about problematic targets like