Author: intrigeri Date: To: Tails user experience & user interface design Subject: Re: [Tails-ux] Clone Persistence option in Tails Installer (#7049)
Hi,
sajolida: > I'd like, most of all, opinions from coders on the cost of such a
> solution
I'll start by asking some clarifications and replying on some
minor points.
> - To prevent people confusing their current Tails with their backup
> Tails, the backup Tails could be aware that it is a backup Tails and
> display some warning when first started. Otherwise, changes made on
> the backup Tails would be overwritten when the backup is updated.
If we can use a bit in the GPT partition flag space (see the ticket
about storing the Tails version number in there for technical
details), then this should be reasonably cheap.
> Before the backup Persistence is being created, the user is prompted for
> a passphrase.
What is this passphrase used for?
> Update
> ------ > Before the backup Persistence is being updated, the user is prompted for
> a passphrase.
Here as well, what for?
> ### Open questions > - Is it fine to copy the content of the current Persistence while it is
> being used?
Doing so creates inconsistent backups: among a set of files that are
supposed to go together (be it config, program data, user data), some
of them are backup'ed at version N while some others at version N+1.
Inconsistent backups ⇒ inconsistent data sets. That can break
software's ability to use the data at various degrees. I can't tell
off-hand how bad this can be but it has the potential to make software
with large and complex data store, such as Thunderbird,
really unhappy.
> - How can we handle the preserve permissions and ownership when doing
> the backup without having users to set up an administration password
> to create or update their backup?
If we work at the filesystem level, i.e. unlocked persistent volume:
I think we'll need a privileged backend. Feasible but much more work
than "a few dozens of lines of code in Tails Installer".
If we work at the block device level, i.e. locked persistent volume:
we need either a privileged backend (as above) or to give the amnesia
user appropriate PolicyKit permissions (which might be too dangerous
to be an option; note that we already give write access to raw block
devices since 9c82fe6a35aa0a3a1fc605d2d5e33b78218f59fc).
> - How much can we organize this code to be easier to possibly extend to
> scenarios S2, S3, and S4 in the future?
I doubt it's a matter of how we organize this code. But some UX +
implementation options will make some of these other scenarios easier
to support than others (see below).
> Future
> ====== > Once we have a solid solution for S1, we might able to reuse some of
> it's UX and code to solve scenarios S2, S3, and S4.
S2 and S4 would probably be easier if we work at the filesystem level.
S3 might be facilitated by working at the block device level (as
opposed to filesystem level).
