Bug #16632
TailsData notification show when setting up persistence in buster
0%
Description
I had to work around this in the automated test suite: we were originally matching against the title “Persistence Wizard - Persistent volume configuration”, but since it it partially blocked (and the notification never disappears unless you hover/click it) I switched to the “Specify the files…” line below instead. Also, a shortcut to TailsData is added in GNOME Places and the GNOME Files sidebar (doesn’t happen when ).
IMHO this notification is a bit invasive and should be suppressed. And exposing access TailsData might lead users to trying to write to it but the amnesia user lack permissions (the potentially writable sub-folders (e.g. Persistent) are created next boot).
Files
Subtasks
Related issues
|
Related to Tails - |
Resolved | ||
| Blocks Tails - Feature #16209: Core work: Foundations Team | Confirmed |
History
#1 Updated by intrigeri 2019-04-05 16:33:24
- blocks Feature #16209: Core work: Foundations Team added
#2 Updated by segfault 2019-04-20 11:08:57
> Also, a shortcut to TailsData is added in GNOME Places and the GNOME Files sidebar (doesn’t happen when )
@anonym: when does this happen? In my feature/buster VM I don’t see a shortcut in GNOME Places or the sidebar
#3 Updated by segfault 2019-04-20 12:37:23
- Assignee set to segfault
#4 Updated by segfault 2019-04-20 19:01:44
- Feature Branch set to bugfix/16632-hide-TailsData
The same happens to me when creating a persistent volume on Tails 3.13, so I wonder why the tests pass on current stable.
The commit on the feature branch (based on stable) should fix this.
#5 Updated by segfault 2019-04-20 19:01:59
- Status changed from Confirmed to In Progress
Applied in changeset commit:tails|504ce047a2ca90cb240636313fa66bb86a50bd06.
#6 Updated by segfault 2019-04-20 19:02:55
- Target version changed from Tails_4.0 to Tails_3.14
We might want to fix this in 3.x, it doesn’t seem to be related to Buster
#7 Updated by segfault 2019-04-21 09:35:20
- Assignee deleted (
segfault) - QA Check set to Ready for QA
Tests passed on Jenkins
#8 Updated by intrigeri 2019-04-26 11:40:30
- Assignee set to segfault
- QA Check changed from Ready for QA to Info Needed
@segfault, good catch!
Is there a simple way to do this without changing the semantics/behaviour (partition label → filesystem label)? If there’s one, let’s do that, so we don’t have to reason about the potential drawbacks of this change.
#9 Updated by segfault 2019-04-27 22:08:52
- Assignee changed from segfault to intrigeri
- QA Check changed from Info Needed to Ready for QA
intrigeri wrote:
> Is there a simple way to do this without changing the semantics/behaviour (partition label → filesystem label)? If there’s one, let’s do that, so we don’t have to reason about the potential drawbacks of this change.
I don’t think so, because IMO the semantics were wrong in the first place. The volume that is shown in the GNOME apps is the unlocked dm device, which is not a partition and thus doesn’t have a partition label. Setting UDISKS_IGNORE on the encrypted partition doesn’t fix that the unlocked volume is shown in the apps, we have to set UDISKS_IGNORE on the unlocked volume instead.
#10 Updated by intrigeri 2019-04-28 07:59:46
> intrigeri wrote:
>> Is there a simple way to do this without changing the semantics/behaviour (partition label → filesystem label)? If there’s one, let’s do that, so we don’t have to reason about the potential drawbacks of this change.
> I don’t think so, because IMO the semantics were wrong in the first place. The volume that is shown in the GNOME apps is the unlocked loop device, which is not a partition and thus doesn’t have a partition label. Setting UDISKS_IGNORE on the encrypted partition doesn’t fix that the unlocked volume is shown in the apps, we have to set UDISKS_IGNORE on the unlocked volume instead.
@segfault, that’s interesting; what you’re saying totally makes sense to me. It’s weird that our Git history suggests that the partition label -based approach did work in the past; perhaps we simply tested it in the wrong way :)
Will now build and manually check what appears in Places with a persistent volume:
- not unlocked
- unlocked in the Greeter
- unlocked manually in the GNOME session
#11 Updated by intrigeri 2019-04-28 08:59:23
- Status changed from In Progress to Fix committed
- % Done changed from 0 to 100
Applied in changeset commit:tails|3dc5dcf9e4b118867ecdd87a3bb25b4cebf4fc9a.
#12 Updated by intrigeri 2019-04-28 09:11:20
- Assignee deleted (
intrigeri) - % Done changed from 100 to 0
- QA Check changed from Ready for QA to Pass
#13 Updated by intrigeri 2019-05-05 08:24:07
- Target version changed from Tails_3.14 to Tails_3.13.2
#14 Updated by anonym 2019-05-06 15:00:19
- Status changed from Fix committed to Resolved
#15 Updated by anonym 2019-05-06 15:03:20
- Target version changed from Tails_3.13.2 to Tails_3.14
#16 Updated by intrigeri 2019-05-06 18:15:45
- Target version changed from Tails_3.14 to Tails_3.13.2
#17 Updated by intrigeri 2019-06-08 10:15:25
- related to
Bug #16789: "Unable to access" error when trying to open the Persistence of another Tails from the Files utility added
#18 Updated by intrigeri 2019-07-07 12:24:12
(I’m coming back here briefly due to Bug #16789 reminding me about a doubt I had.)
@segfault wrote:
> The volume that is shown in the GNOME apps is the unlocked dm device, which is not a partition and thus doesn’t have a partition label.
I believe that’s true for an unlocked encrypted device, but unlocked devices do appear in the GNOME Files sidebar as well: on my system, I see a “32 GB Encrypted” item there when I plug a USB stick with a LUKS-encrypted partition. But its GPT partition name is not displayed. And this udev rule does prevent displaying “32 GB Encrypted” in GNOME Files’ sidebar: ENV{ID_PART_ENTRY_NAME}=="TailsData", ENV{UDISKS_IGNORE}="1". So if we wanted to hide locked encrypted persistent volumes, we could do that.