Tails

#5 Updated by intrigeri 2019-06-08 10:15:11

Reproduced on Tails 3.14. The logs say udisksd[5524]: Unlocked LUKS device /dev/sda2 as /dev/dm-0 and indeed, the persistent volume was unlocked; but the filesystem it contains was not mounted, the “Encrypted” item in the sidebar disappears, and no “TailsData” volume replaces it; going to GNOME Disks and clicking the “Play” icon there to mount it works fine.

Commenting out the rule in config/chroot_local-includes/etc/udev/rules.d/99-hide-TailsData.rules, running sudo udevadm control --reload, and replugging stick B fixed the problem.

> You can still mount the partition from the Disks utility, but I really want to avoid having to document this on these pages.

The behavior you’re experiencing is caused by our desire to hide the persistent filesystem (“TailsData”) from the sidebar, in order to:

• fix a UX problem in GNOME Files (see commit:791cab4b6f075ee9753cac08895acb2f008a7e71 for background)
• avoid spurious notifications (e.g. Bug #16632) when setting up persistence, i.e. another UX problem

Presumably that’s why wiki/src/doc/first_steps/persistence/copy.mdwn has always documented how to mount such a volume from GNOME Disks: historically, we could not rely on GNOME Files to do so. It only worked for you in 3.11 because of a bug, then I’m not quite sure about 3.12 (we updated udev there), and eventually segfault fixed that bug in 3.13.2. Unfortunately, fixing that bug (and the corresponding UX problems) introduced the other issue you’re raising here.

sajolida, do I understand correctly that you would like to migrate the existing doc from mounting with GNOME Disks to mounting with GNOME Files? This would require us to find a technical solution that allows this; FYI, I don’t expect it’ll be easy and I’m not even sure it’s possible. I suspect that in the end, we’ll have to choose between the annoyance of documenting/following these operations in GNOME Disks, vs. the annoyances that we would cause if we removed the udev rule that hides TailsData.

@segfault, is there a simple way to hide the TailsData filesystem from the boot device, without hiding those that are on other devices?

#8 Updated by sajolida 2019-06-12 16:50:41

I did more tests with historical versions and it has been possible to mount a Persistence from another Tails since at least 2.2 (from March 2016, the oldest version I have on my disks). So I think that the error I’m describing here is a regression introduced only in 3.12.

I’m still not sure to understand what would be the UX cost of going back to the behavior we had for years before 3.12:

• Is 791cab4b6f about hiding TailsData from Places only after Persistence was created and until Tails is restarted? (because I otherwise don’t see any TailsData in Places, even with a locked Persistence in 3.14).
• Removing the udev rule in /etc/udev/rules.d/99-hide-TailsData.rules would display TailsData for the current Tails only if Persistence is disabled (but not if it’s enabled).

If Bug #16632 was introduced by the udev upgrade, could we find another fix that doesn’t introduce the regression I’m describing here?

I don’t remember why I wrote instructions with GNOME Disks back in 2013 but I can see at least that some of our objectives have changed. We wrote them as if the old Tails couldn’t be trusted (cf. “Do not use the Tails USB stick that might be corrupted in the process of installing the new one.”). It’s unrelated to this particular issue but it proves that we’re now approaching the problem from a very different angle (and somehow that we also went a long way in the direction of simplifying things for users since then).

#9 Updated by segfault 2019-06-13 20:41:26

intrigeri:
> @segfault, is there a simple way to hide the TailsData filesystem from the boot device, without hiding those that are on other devices?

udev rules don’t seem to provide the means for that directly, but it allows executing a program in a rule (see PROGRAM in the udev man page). So we could create a is-boot-device tool to only hide the TailsData of the device we booted from.

#11 Updated by intrigeri 2019-07-06 19:47:49

Hi!

> I did more tests with historical versions and it has been possible to mount a Persistence from another Tails since at least 2.2 (from March 2016, the oldest version I have on my disks). So I think that the error I’m describing here is a regression introduced only in 3.12.

OK.

> I’m still not sure to understand what would be the UX cost of going back to the behavior we had for years before 3.12:

I agree this is the best way to frame this problem.

> * Is 791cab4b6f about hiding TailsData from Places only after Persistence was created and until Tails is restarted?

Reading that commit, it seems that this todo was originally about the unlocked persistence volume showing up in the Places menu. It’s not the case anymore as of 3.14.2, be it with our without our udev rule, so I think this specific problem is moot.

> * Removing the udev rule in /etc/udev/rules.d/99-hide-TailsData.rules would display TailsData for the current Tails only if Persistence is disabled (but not if it’s enabled).
> If Bug #16632 was introduced by the udev upgrade, could we find another fix that doesn’t introduce the regression I’m describing here?

Removing this udev rule would not change anything at all for a locked persistent volume. This udev rule only affects an unlocked filesystem whose name is TailsData, which occurs in three main cases in Tails:

• Persistent volume unlocked in the Greeter. For some reason, apparently it’s not shown in the GNOME Files sidebar nor in Places, regardless of udev rules. I would guess it’s because of the complex mounts situation we have for this filesystem, which might confused some part of the storage stack; or, that’s because we already display some links to it (“Persistent”), so GNOME Files de-duplicates. I don’t know. In any case, this one does not cause trouble at the moment.
• While setting up persistence (Bug #16632).
• After unlocking a persistent volume from another USB stick, i.e. the problem this ticket is about.

So it seems that the only UX cost that removing the udev rule would have is to reintroduce Bug #16632. Unfortunately, IMO it’s a serious issue: if the user clicks the notification, I’m pretty sure that’ll break the persistence setup process.

The fact that Bug #16632 did not occur in Tails 3.x before 3.12 was probably due to a bug that got fixed in udev: we were lucky to get the inconsistent behavior we wanted¹ but that does not mean that udev has to behave inconsistently: it can cause other problems down the road. I don’t think that reintroducing this udev bug is a sustainable approach.

So I think the only viable option we have at the moment is the technical solution suggested by segfault. If it works, then it would fix the problem this ticket is about without reintroducing Bug #16632. It’s worth a try :) @segfault, do you want to try it?

[1] The problem is, the behavior we want here is indeed inconsistent from the udev / udisks / GNOME point of view: it seems we want the system to consider unlocked persistent volumes as relevant in the GUI in some cases (as shown by this ticket), but not in others (as seen in Bug #16632). Unsurprisingly, that’s not supported out of the box by udev / udisks / GNOME. I hope segfault’s idea works and allows us to enforce the behavior we want. If it does not work, then I’m not very hopeful we can get what we want here: there’s no other way, AFAIK, to have udev / udisks / GNOME behave differently on essentially identical storage volumes, depending on whether they’re stored on the boot medium or not.

> I don’t remember why I wrote instructions with GNOME Disks back in 2013 but I can see at least that some of our objectives have changed. We wrote them as if the old Tails couldn’t be trusted (cf. “Do not use the Tails USB stick that might be corrupted in the process of installing the new one.”). It’s unrelated to this particular issue but it proves that we’re now approaching the problem from a very different angle (and somehow that we also went a long way in the direction of simplifying things for users since then).

IIRC you wrote this doc in 2013 after we discovered that dangerous permissions were set on persistence config files so we needed a way for users to recover their data, without trusting these files. I thought we also pointed to this doc for users who want to salvage their data after losing trust in their Tails system (the current version of this doc would mostly work for this user scenario and I’ve pointed users to it for this reason) but apparently I remembered it wrong: I can’t find traces of it anywhere. I hope the updated backup doc will incidentally make it easier to recover from such a situation, at least for users who do backups :)

#16 Updated by sajolida 2019-07-18 16:49:51

Sweet!

#19 Updated by segfault 2019-08-01 09:51:41

intrigeri wrote:
> @segfault, elsewhere, to determine if a block device is on the boot medium, we use /lib/bilibop/test. At first glance it does exactly what we want, i.e. it returns 0 if I pass it /dev/mapper/TailsData_unlocked; I did not test it on a Persistence that’s not on the boot device but it’s supposed to work there too (i.e. return 1).

Indeed, that seems to work. A bit frustrating to see that I spent a lot of time on implementing something that was already there, and which we already use.

I pushed a commit which uses /lib/bilibop/test.

#22 Updated by intrigeri 2019-08-01 10:40:41

> A bit frustrating to see that I spent a lot of time on implementing something that was already there, and which we already use.

Yeah, sorry I did not think about this back when were brainstorming potential solutions :/

#23 Updated by intrigeri 2019-08-01 11:00:14

Code review passes, will test manually wrt. the problem this ticket is about + will wait for Jenkins test results.

#24 Updated by intrigeri 2019-08-04 09:58:18

> will test manually wrt. the problem this ticket is about

I confirm this branch fixes the bug, will merge.

(In passing: trying to unlock the locked persistent volume that’s on the boot medium fails with the same error that sajolida reported here initially, but that’s expected.)

> will wait for Jenkins test results.

It’s happy enough.