Feature #9280
Jessie: Ensure that the persistent volume is not managed by GNOME while it's being created
100%
Description
It could be that when t-p-s is creating the persistent volume, udisks2/Nautilus automount it and a notification is displayed (see Feature #5938 for a similar problem that was addressed in Tails Installer). We should check if that’s the case, and if it is, evaluate what are the potential problems it would cause. And if we need to prevent that:
- see how gparted handles this: https://bugzilla.gnome.org/show_bug.cgi?id=745349 and https://git.gnome.org/browse/gparted/commit/?id=4acb8e4fbb9e01d33cc1e9fd89686a3818050690
- see if we can use a trick similar to the Tails Installer’s one to make udisks2 temporarily mark the newly created volume as hidden, and revert that trick before quitting t-p-s.
Subtasks
Related issues
|
Related to Tails - |
Resolved | ||
|
Related to Tails - |
Resolved | 2014-11-23 |
History
#1 Updated by intrigeri 2015-04-26 04:07:51
- related to
Feature #5938: liveusb-creator should prevent GNOME from managing the target device added
#2 Updated by intrigeri 2015-04-26 04:08:04
- related to
Feature #8291: Port tails-persistence-setup and perl5lib to UDisks2 added
#3 Updated by BitingBird 2015-04-26 08:55:47
- Subject changed from Ensure that the persistent volume is not managed by GNOME while it's being created to Jessie: Ensure that the persistent volume is not managed by GNOME while it's being created
#4 Updated by intrigeri 2015-08-02 08:58:28
- Due date set to 2015-10-15
- Target version changed from Tails_2.0 to Tails_1.6
#5 Updated by intrigeri 2015-08-02 08:58:56
- blocks #8668 added
#6 Updated by intrigeri 2015-09-16 13:23:17
- Status changed from Confirmed to Resolved
- Assignee deleted (
intrigeri) - % Done changed from 0 to 100
I was not able to trigger this problem.
I’ve looked at the code and we’re asking udisks2 to mount the newly created filesystem basically immediately after it tells us it’s been created. I’ve gone through this with udisksctl monitor running, and what I see is less than 300 ms between the end of the persistent filesystem creation job, and the beginning of the one that mounts it. That’s basically the duration of that theoretical race condition in my environment, so I’m not convinced that fixing it is worth the effort.
To end with, the GNOME automounter is not configured to automount filesystems nor display notifications when they’re plugged, so the only issue we could possibly have is if we were unmounting the filesystem (we could get a “You can now remove device XXX” notification). But t-p-s doesn’t do that when creating a persistent volume. It only does that when deleting one, and only if the persistent volume is mounted, and I was not able to make it happen in this exact context.
So I’m going to call this problem highly theoretical and close this ticket. If someone sees it happen, let’s reopen it.
(
If we really want to fix it, GParted’s trick won’t work for us as-is: it uses /usr/lib/udisks2/udisks2-inhibit, that “Disallow(s) udisks2 mount operations for anyone but root while a program is running”. And the action we ourselves want to trigger while we inhibit udisks is precisely… a mount. However we could do either of:
- do the same as
udisks2-inhibitdoes, but with a different pkla, if we can express “nobody but the t-p-s user” in there; - try to find a way to temporarily disable the GNOME automounter, e.g. via dconf.
)