Bug #12413

Creation/deletion of persistent volume requires admin password in 3.0-beta3

Added by mercedes508 2017-03-31 12:29:46 . Updated 2017-05-01 17:30:36 .

Status:
Rejected
Priority:
Normal
Assignee:
mercedes508
Category:
Persistence
Target version:
Start date:
2017-03-31
Due date:
% Done:

0%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

When willing to create or delete a persistent volume in Tails-3.0-beta3, user is asked for an admin password.

If no admin password if given I get the following:

org.freedesktop.UDisks2.Error.NotAuthorizedDismissed: The authentication dialog was dismissed

If an admin password if given it works as expected.


Subtasks


History

#1 Updated by mercedes508 2017-03-31 13:29:51

This issue was experienced on a Tails USB installed using Tails Installer (in Debian).

#2 Updated by intrigeri 2017-04-01 07:54:37

  • Assignee changed from anonym to mercedes508
  • QA Check set to Info Needed

> When willing to create or delete a persistent volume in Tails-3.0-beta3, user is asked for an admin password.

> If no admin password if given I get the following:

> org.freedesktop.UDisks2.Error.NotAuthorizedDismissed: The authentication dialog was dismissed

I can’t reproduce this, and our test suite can’t either :/ So I’m wondering what’s going on.

Is there anything special about the device you started Tails from?

Can you reproduce this with Tails 2.11 on the very same device, installed exactly the same way?

Also, please retry this way:

  1. Modify /usr/local/bin/tails-persistence-setup so that it calls DEBUG=1 /usr/bin/tails-persistence-setup instead of /usr/bin/tails-persistence-setup
  2. Run the tails-persistence-setup command in a (non-root) terminal

… and attach the full output of the command here (or send it to me privately if you prefer).

#3 Updated by mercedes508 2017-04-06 09:47:27

  • Assignee changed from mercedes508 to intrigeri
  • QA Check changed from Info Needed to Dev Needed

Hi,

> Is there anything special about the device you started Tails from?

No that’s a regular USB stick (Lexar 8Gb). Tails 3.0-beta3 was installed first using Tails Installer in Debian to install Tails 3.0-beta2, then automatic upgrade to version beta3.

> Can you reproduce this with Tails 2.11 on the very same device, installed exactly the same way?

I’m not asked for an admin password with Tails 2.11 on the same device, installed using Tails Installer.

FWIW it doesn’t happen on Tails 3.0-beta2.
I upgraded that Tails 3.0-beta2 USB to Tails 3.0-beta3 through automatic upgrade and was able to reproduce the error.

> # Modify /usr/local/bin/tails-persistence-setup so that it calls DEBUG=1 /usr/bin/tails-persistence-setup instead of /usr/bin/tails-persistence-setup
> # Run the tails-persistence-setup command in a (non-root) terminal
>
> … and attach the full output of the command here (or send it to me privately if you prefer).

done privately.

#4 Updated by intrigeri 2017-04-10 16:23:05

  • Assignee changed from intrigeri to mercedes508
  • QA Check changed from Dev Needed to Info Needed

mercedes508: you might want to skip the boring technical discussion and jump to the end, where there are questions for you :)

> FWIW it doesn’t happen on Tails 3.0-beta2.

I’ll assume that “it” means “the problem this ticket is about”. I’ve had a look at the Git and packages list diff between beta2 and beta3, and the only potentially relevant changes are: installing dbus-user-session and upgrading udev (232-18 to 232-19). I see nothing relevant in the udev changelog, but dbus-user-session might be relevant: we run tails-persistence-setup as a dedicated user, so this change might indirectly impact how the communication with the system D-Bus daemon works, and then how the communication with the UDisks2 D-Bus service is done. Note, however, that all read-only operations do work, and what fail seems to be the first write operation, so at least we know that tails-persistence-setup can communicate with UDisks2.

>> # Modify /usr/local/bin/tails-persistence-setup so that it calls DEBUG=1 /usr/bin/tails-persistence-setup instead of /usr/bin/tails-persistence-setup
>> # Run the tails-persistence-setup command in a (non-root) terminal
>>
>> … and attach the full output of the command here (or send it to me privately if you prefer).

> done privately.

Thanks! (By the way, forget the DEBUG=1 thing that can’t possibly work without additional config, just run tails-persistence-setup --verbose.)

The relevant bits of the log, sanitized of any personal info, are:

Running step bootstrap
Entering main Gtk3 loop.
Entering create_persistence_partition
Creating partition of size X,YYGiB at offset XXX on device /dev/sda
waiting...
Entering create_persistent_encrypted_filesystem
Entering Bootstrap::operation_finished
org.freedesktop.UDisks2.Error.NotAuthorizedDismissed: The authentication dialog was dismissed

So the problem looks like a polkit one. Given there’s no “waiting…” for create_persistent_encrypted_filesystem, we know that this method is merely relaying the error reply sent by UDisks2 to the D-Bus call initiated in create_persistence_partition, i.e. the first modification we try to do on the device. Note that we already had to do weird stuff around these permissions in commit:84ebee235723a296bd7be7be6cbc7e1fb0b648e9, i.e. there’s some confusion going on wrt. who’s talking to UDisks2 when we run an application with sudo, and I suspect that the systemd/logind integration brought by dbus-user-session might impact this a bit (technically tails-persistence-setup runs within a “seat” that’s controlled by the amnesia user).

So, mercedes508, I need your help! I can’t reproduce this (I’ve just tried on bare metal, and had already tried in a VM) so we’ll have to debug this remotely. If it helps we can schedule an appointment on XMPP.

Meanwhile, please try the following:

  1. Run sudo systemctl edit udisks2.service, and in there write two lines: the first one shall contain [Service], the second line shall contain ExecStart=/usr/lib/udisks2/udisksd. Save and exit.
  2. Run sudo systemctl restart udisks2.service.
  3. Edit /etc/polkit-1/localauthority/10-vendor.d/org.boum.tails.pkla as root. In there, copy the first 6-lines paragraph (“Modify internal storage devices”), paste it twice, and:
    1. leave the original alone
    2. in the 1st copy, replace modify-device-system with modify-device-other-seat
    3. in the 2nd copy, replace modify-device-system with modify-device
  4. Finally, try to reproduce the bug, and don’t enter an admin password when prompted. If you can reproduce the bug, please sent me the (WhisperBack) logs from that session. Else, if you can’t reproduce the bug anymore, then please delete one of the 2 copies of the config snippet, then the other, until you’re pinpointed which one fixes the problem for you (might be that you need both though).

Thanks in advance :)

#5 Updated by mercedes508 2017-04-20 12:26:47

  • Status changed from Confirmed to Resolved
  • Assignee changed from mercedes508 to intrigeri

I didn’t took time to do what you asked for, but I just tried with 3.0-beta4 and the bug is apparently gone. So closing this ticket for now.

#6 Updated by intrigeri 2017-04-29 11:53:22

> I didn’t took time to do what you asked for, but I just tried with 3.0-beta4 and the bug is apparently gone. So closing this ticket for now.

This outcome saddens me a little bit for two reasons:

  • I doubt the problem was really resolved. I bet it’ll reappear at some point once 3.0 is out and thousands of people are exposed to the affected code, and then we’ll need to deal with it in a hurry instead of in a more relaxed way (which would be the case if we handled this before 3.0 is out);
  • I’ve spent quite some time investigating this problem and documenting debugging steps, and now I feel that I’ve somewhat wasted my time (but that’s not really true since I expect this work will be useful whenever someone else hits this bug).

Now, I understand if you don’t want to spend more time on this than you already did. “Hopefully” someone else will suffer of this problem enough to go through the debugging steps I’ve documented :)

#7 Updated by intrigeri 2017-04-29 11:54:44

  • Status changed from Resolved to Rejected
  • Assignee deleted (intrigeri)

#8 Updated by mercedes508 2017-05-01 17:30:36

  • Assignee set to mercedes508

Well I still can try your debugging steps for sure.