Tails

#1 Updated by anonym 2016-06-15 15:16:01

• Status changed from Confirmed to In Progress
• Assignee changed from anonym to segfault
• % Done changed from 0 to 30
• QA Check set to Info Needed
• Feature Branch set to feature/11533-persistent-bind-mounted-files

Does this branch give you what you need?

If it helps, you can activate persistence during a running Tails session with:

# Find the $VOLUME storing the persistence, if you don't already know it :)
/usr/local/sbin/live-persist list

# Activate persistence on $VOLUME
/usr/local/sbin/live-persist activate $VOLUME

# Deactive it. I'm not sure how well this one works, otherwise just
# manually `umount` + `cryptsetup luksClose`.
/usr/local/sbin/live-persist close $VOLUME

This CLI might be useful for you in Tails Server, to immediately enable new persistence presets but there might be some additional work needed for that.

#2 Updated by segfault 2016-06-16 12:39:29

• Assignee changed from segfault to anonym
• QA Check deleted (Info Needed)

The bind-mounting of files works! Awesome! :)

I don’t get what live-persist does and how to use it.

This doesn’t print anything:
live-persist list

If I run this, it just keeps printing newlines indefinitely:
live-persist /dev/sda2 # where /dev/sda2 is my persistent volume, which was already unlocked on boot

I currently just copy the files / directories I want to make persistent to /live/persistence/TailsData_unlocked and bind-mount them to immediately enable new persistence settings.

#3 Updated by anonym 2016-06-17 10:27:39

• Assignee changed from anonym to segfault
• % Done changed from 30 to 40
• QA Check set to Info Needed

segfault wrote:
> The bind-mounting of files works! Awesome! :)

Cool! So the next steps for me is to figure out how to upstream this. Also, I’ll need to update the man page. And probably I should go pack in and fix some variable names, since they seem to indicate that only directories can be persistent.

> I don’t get what live-persist does and how to use it.
>
> This doesn’t print anything:
> live-persist list

I actually meant:

live-persist --encryption=luks list TailsData

:)

Forget about what I said so far, and let’s start from scratch: imagine you’ve logged in to Tails with persistence enabled. Then you can do this:

mkdir /live/persistence/TailsData_unlocked/foo
echo "success" > /live/persistence/TailsData_unlocked/foo/test
echo "/home/amnesia/bar source=foo" >> /live/persistence/TailsData_unlocked/persistence.conf
live-persist activate /dev/mapper/TailsData_unlocked
cat /home/amnesia/bar/test

and that should print success, i.e. the new persistence dir was “hot”-enabled. I think this is exactly what you’d like to have for Tails Server.

> If I run this, it just keeps printing newlines indefinitely:
> live-persist /dev/sda2 # where /dev/sda2 is my persistent volume, which was already unlocked on boot

Yeah… in live-persist we are calling some things that are not really supposed to be run outside the boot process… :) At this point any LUKS volume must be open already, but luckily that is the case for the Tails Server context.

> I currently just copy the files / directories I want to make persistent to /live/persistence/TailsData_unlocked and bind-mount them to immediately enable new persistence settings.

The equivalent with live-persist would be: “copy the files / directories I want to make persistent to /live/persistence/TailsData_unlocked”, add a suitable line to persistence.conf, and then run live-persist activate /dev/mapper/TailsData_unlocked. Also, you can even skip the “copy the files …” part if you want the source dir to contain everything of the destination dir — when the source dir doesn’t exist, it is bootstrapped with the contents of the destination (or an empty dir, if the destination doesn’t exist).

I think there might be a point that we try to use live-persist here, instead of re-implementing similar logic again. What do you think?

BTW, we have an interesting situation for Tails Server when persistence is enabled as read-only. I think we should support starting services that ware set up persistently in previous sessions in read-only mode, which means that it will run as configured, but any new changes are lost after reboot. I quite like that, as it brings the amnesia feature to Tails Server for those that want it. :)

However, in that situation Tails Server should not allow marking a newly activated service as persistent (it should be treated just like if persistence was completely disabled). That is actually the only thing you’d have to implement in Tails Server — the rest you get for free thanks to the persistence backend.

If you want to know how to check if persistence is enabled as read-only, see persistence_is_enabled_read_write() (so, the opposite!) in config/chroot_local-includes/usr/local/lib/tails-shell-library/tails-greeter.sh.

#4 Updated by anonym 2016-09-20 16:54:10

• Target version changed from Tails_2.6 to Tails_2.7

#5 Updated by bertagaz 2016-11-17 17:38:35

• Target version changed from Tails_2.7 to Tails_2.9.1

#6 Updated by anonym 2016-12-14 20:11:25

• Target version changed from Tails_2.9.1 to Tails 2.10

#7 Updated by anonym 2017-01-24 20:48:50

• Target version changed from Tails 2.10 to Tails_2.11

#8 Updated by segfault 2017-02-14 17:36:36

• Assignee changed from segfault to anonym

I completely forgot about this ticket :/
I think we talked about this in the summer, but I’m not completely sure.
S for the record: I am currently not using the persistence.conf in Tails Server. Instead, I mount --bind the files / directories directly, both when the persistence option is enabled and when tails-service --restore is executed. To mount the persistent paths during startup, I added a systemd unit chroot_local-includes/lib/systemd/system/tails-server-persistence.service which executes tails-service --restore after boot.

Do you think it is ok this way, or would you prefer it if I used the persistence.conf and live-persist instead? Maybe you can decide this during the code review.

Also, I noticed that feature/5688-tails-server contains commit 305e4933, which fixes this issue. But I don’t understand how it got there.

#9 Updated by anonym 2017-02-17 12:09:10

• File 0001-Patch-live-boot-to-support-bind-mounting-individual-.patch added

segfault wrote:
> I completely forgot about this ticket :/
> I think we talked about this in the summer, but I’m not completely sure.
> S for the record: I am currently not using the persistence.conf in Tails Server. Instead, I mount --bind the files / directories directly, both when the persistence option is enabled and when tails-service --restore is executed. To mount the persistent paths during startup, I added a systemd unit chroot_local-includes/lib/systemd/system/tails-server-persistence.service which executes tails-service --restore after boot.
>
> Do you think it is ok this way, or would you prefer it if I used the persistence.conf and live-persist instead? Maybe you can decide this during the code review.

I think it’d be nice to use the same persistence framework everywhere, but it was not designed for that really, and quite possibly my patch won’t be enough. If you have the time and interest, play around with the instruction I have you in Bug #11533#note-3 to see if it’d be good enough for your needs. Otherwise just forget about it and feel free to close this ticket.

> Also, I noticed that feature/5688-tails-server contains commit 305e4933, which fixes this issue. But I don’t understand how it got there.

I probably put it there. Please revert the commit if you end up not using it.

(I’m attaching the live-persist patch to this ticket for posterity, in case we dig up this ticket at some point because we want this feature for other reasons.)

#10 Updated by anonym 2017-02-17 12:09:23

• Assignee changed from anonym to segfault

#11 Updated by segfault 2017-02-18 14:15:38

• related to Bug #12253: Use persistence.conf in Tails Server added

#13 Updated by intrigeri 2017-03-03 08:06:16

• Target version changed from Tails_2.11 to Tails_2.12

Not suitable for a point-release => removing from the 2.11 RM view.

#14 Updated by intrigeri 2017-04-20 06:56:30

• Target version deleted (Tails_2.12)

Apparently this doesn’t block anything, so dropping the target version to make our Release Manager views more useful and usable. Feel free to re-add a (realistic) one if this helps you organize your work :)

#16 Updated by segfault 2018-01-16 10:45:00

• Assignee changed from segfault to anonym
• Target version set to Tails_3.9
• QA Check deleted (Info Needed)

u wrote:
> @segfault, would you like to set a target version for this?
Yeah, I want this for Tails Server, so I guess I it makes sense to set it to the same target version.

> I’m unsure what the current status of this ticket is. Is info still needed? If not, please drop it.

The current status seems to be that I said I would check if this is what I need when I work on Bug #12253.
Update: This seems to be exactly what I need :) I reassign this to anonym now, so he can continue with the next steps he lists in Bug #11533–3.

#17 Updated by intrigeri 2018-05-25 13:25:36

• Target version deleted (Tails_3.9)