Bug #12413
Creation/deletion of persistent volume requires admin password in 3.0-beta3
0%
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:
- Modify
/usr/local/bin/tails-persistence-setup
so that it callsDEBUG=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).
#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:
- Run
sudo systemctl edit udisks2.service
, and in there write two lines: the first one shall contain[Service]
, the second line shall containExecStart=/usr/lib/udisks2/udisksd
. Save and exit. - Run
sudo systemctl restart udisks2.service
. - 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:- leave the original alone
- in the 1st copy, replace
modify-device-system
withmodify-device-other-seat
- in the 2nd copy, replace
modify-device-system
withmodify-device
- 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.