Project

General

Profile

Feature #9280

Jessie: Ensure that the persistent volume is not managed by GNOME while it's being created

Added by intrigeri almost 5 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
Start date:
04/26/2015
Due date:
10/15/2015
% Done:

100%

Feature Branch:
Type of work:
Test
Blueprint:
Starter:
Affected tool:

Description

It could be that when t-p-s is creating the persistent volume, udisks2/Nautilus automount it and a notification is displayed (see #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:


Related issues

Related to Tails - Feature #5938: liveusb-creator should prevent GNOME from managing the target device Resolved
Related to Tails - Feature #8291: Port tails-persistence-setup and perl5lib to UDisks2 Resolved 11/23/2014

History

#1 Updated by intrigeri almost 5 years ago

  • Related to Feature #5938: liveusb-creator should prevent GNOME from managing the target device added

#2 Updated by intrigeri almost 5 years ago

  • Related to Feature #8291: Port tails-persistence-setup and perl5lib to UDisks2 added

#3 Updated by BitingBird almost 5 years ago

  • 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 over 4 years ago

  • Due date set to 10/15/2015
  • Target version changed from Tails_2.0 to Tails_1.6

#6 Updated by intrigeri over 4 years ago

  • 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-inhibit does, 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.
    )

Also available in: Atom PDF