Project

General

Profile

Bug #16789

"Unable to access" error when trying to open the Persistence of another Tails from the Files utility

Added by sajolida about 1 month ago. Updated 4 days ago.

Status:
Needs Validation
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
bugfix/16789-unable-to-access-persistence
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

  1. Start Tails from USB stick A.
  2. Plug in Tails USB stick B which has a Persistence.
  3. Click the new "Encrypted" label in the sidebar of the Files browser.

See the following error message in attachment.

It means that people can't follow https://tails.boum.org/doc/first_steps/persistence/copy/ anymore (even if I fixed all its bugs).

It's also blocking me from proposing a good solution to all the related tickets (#14605, #12214, etc.).

This appeared in 3.12 (3.11 is not affected). It's a regression so → Priority: Elevated.

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

unable.png View (9.23 KB) sajolida, 06/07/2019 05:03 PM


Related issues

Related to Tails - Bug #16632: TailsData notification show when setting up persistence in buster Resolved
Blocks Tails - Feature #14605: Improve documentation on "Manually copying your persistent data to a new USB stick" Confirmed 09/05/2017
Blocks Tails - Feature #16209: Core work: Foundations Team Confirmed 03/22/2019

Associated revisions

Revision 214130c6 (diff)
Added by segfault 15 days ago

Add comment explaining why we hide TailsData partitions (refs: #16789)

Revision 60d0c9aa (diff)
Added by segfault 15 days ago

Update comment (refs: #16789)

The first mentioned reason seems to be obsolete: there is no error when clicking
TailsData in the places sidebar when this rule is deleted. And it's not
listed anywhere else (e.g. the Places menu in the top bar or "Other locations"
in Nautilus).

Revision d06918e6 (diff)
Added by segfault 15 days ago

Only hide unlocked TailsData partitions from the boot device (refs: #16789)

History

#1 Updated by sajolida about 1 month ago

#2 Updated by sajolida about 1 month ago

  • Blocks Feature #14605: Improve documentation on "Manually copying your persistent data to a new USB stick" added

#3 Updated by intrigeri about 1 month ago

#4 Updated by intrigeri about 1 month ago

  • Status changed from Needs Validation to Confirmed

(I see nothing that's ready for validation here. I'll do some initial triaging.)

#5 Updated by intrigeri about 1 month ago

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:

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?

#6 Updated by intrigeri about 1 month ago

  • Related to Bug #16632: TailsData notification show when setting up persistence in buster added

#7 Updated by sajolida about 1 month ago

  • Subject changed from "Unable to access" error when trying to open another stick's Persistence from Files to "Unable to access" error when trying to open the Persistence of another Tails from the Files utility

#8 Updated by sajolida about 1 month ago

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 #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 about 1 month ago

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.

#10 Updated by intrigeri 16 days ago

  • Description updated (diff)

(Fix link to doc.)

#11 Updated by intrigeri 16 days ago

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 #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 (#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 #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 #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 #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 #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 :)

#12 Updated by segfault 15 days ago

  • Status changed from Confirmed to In Progress

#13 Updated by segfault 15 days ago

  • Status changed from In Progress to Needs Validation
  • Feature Branch set to bugfix/16789-unable-to-access-persistence

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 #16632. It's worth a try :) @segfault, do you want to try it

I pushed a commit which seems to achieve this.

I also added a comment to the udev rule to explain why we need it, using intrigeri's findings from #16789#note-5. But then I noticed that I can't reproduce the UX problem in GNOME Files (791cab4b6f075ee9753cac08895acb2f008a7e71).

So now the only reason seems to be the spurious notification when setting up the persistent volume (i.e. #16632). On the other hand, it might actually be useful for users to be able to more easily access the TailsData partition when they didn't unlock it in the greeter. For example to back up the content to another device - this would allow a pretty easy and straightforward backup/restore method: Boot Tails without unlocking the partition, plug in another Tails or other encrypted volume, copy the files via Nautilus.

Note that even without the udev rule, a TailsData partition unlocked via the greeter is not shown in Nautilus.

#14 Updated by segfault 15 days ago

  • Target version set to Tails_3.15

#15 Updated by segfault 15 days ago

  • Target version changed from Tails_3.15 to Tails_3.16

#16 Updated by sajolida 4 days ago

Sweet!

Also available in: Atom PDF