GNOME Bugzilla – Bug 730759
Attempting to mount a file volume twice will delete the stored password
Last modified: 2018-09-21 17:41:58 UTC
Using gnome-disk-image-mounter on a file will cause a loopback device to be created. If the loopback device had LUKS on it, it will ask for a password that can be remembered. Saving the password records the gvfs-luks-uuid in gnome-keyring. Once the device has been unlocked and mounted, attempting to mount it again using gnome-disk-image-mounter will not warn you that the volume is already mounted, or use the previous password, but instead create a second loopback device and delete/wipe/forget the previous password. Even if this dialog is then cancelled, the previous password has already been removed, which could cause users who accidentally attempt to double mount a file severe data loss if they can't remember their previous passwords (expecting them to be faithfully saved). I'm not sure whether this should be a gnome-keyring issue about how easily a program can delete/overwrite stored passwords, or whether it's an issue of gnome-disk-utility in particular, but I figured this one definitely needed fixing and gnome-keyring would need further discussion. Steps to recreate: 1. Make sure some extension like .volume is associated with gnome-disk-image-mounter. 2. Create a new LUKS volume somehow, and give it a .volume file extension. 3. Start gnome-keyring next to nautilus so you can see both side-by-side. 4. Double click the file to attempt mounting it, a box with "Enter password for /dev/loop0" will appear. 5. Enter the correct password, ensure the save password box is ticked, and hit ok. 6. See the password entry appear in gnome-keyring, stored with the gvfs-luks-uuid to identify it. 7. Double click the same .volume file with it already mounted. 8. See the dialog box asking for the password for /dev/loop1 appear, and in the background see the password having been removed from gnome-keyring (despite it being the same volume and thus the same gvfs-luks-uuid), even before the enter password dialog box has had a response.
Thanks for reporting this. Which version is this about?
Oh, sorry, this is with 3.12.1 but I suspect it also happens with 3.10.0...
This is a problem with gvfs's udisks2 backend, not gnome-disk-utility. Reassigning. (I'll look in detail later, given that I also wrote that code.)
> gnome-disk-image-mounter will not warn you that the volume is already mounted Do you believe it should? (If so, this is not a gvfs bug.) FWIW, I don't think it should warn you in this case. You can argue that the setup-disk-image operation should fail if you attempt to do it twice in a non-read-only way. If we made that change, this whole problem would go away, wouldn't it?
No, I don't really believe it should, I'm just not sure how linux handles having the same filesystem mounted twice. I expected gvfs to figure out that the LUKS volume was the same, and use the existing key to unlock it (again). The primary aim of this bug is to ensure that it never silently wipes a stored password. Whether the operation can succeed or fail is sort of secondary. I don't know enough about the internals of gvfs-udisks, but if there's still code lurking in gvfs that allows passwords to vanish or be replaced, then that's the core issue. Finding a fix for this one specific instance isn't really the goal, since there may be another place where the same code wipes a password.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/234.