GNOME Bugzilla – Bug 768769
gnome-disks should allow automatic unlock of drives with keys in the gnome-keyring at login
Last modified: 2017-05-09 14:13:31 UTC
Created attachment 331405 [details] Screenshot of the default encryption options Hi there, It should be possible to unlock an encrypted drive or partition that's present at login as long as the credentials are in an unlocked keyring at login time. At the moment I have to manually go to nautilus, click on other locations (because drives are no longer shown in the sidebar, nor can they be bookmarked) and then click the drive to mount it. Another option is to start gnome-disks and manually mount it. At no point are credentials required, so these are just unnecessary clicks. I've looked into setting up a program to unlock these at login time, unfortunately udisksctl does not make use of gnome-keyring and demands a passphrase even when run as the user with the unlocked keyring, and gnome-disks does not provide sufficient command line options to unlock a drive on command. This is made more confusing by the default options for encrypted drives being "unlock at startup" (and "mount at startup" in mount options) as shown in the attached screenshot. This is quite inconvenient and feels like it would be a quick win for usability of gnome-disks/udisks/nautilus in working with encrypted drives. Please could you implement some solution to this problem, ideally something that automatically mounts encrypted drives marked "start automatically" at login time, but failing that at least a command line tool that can be launched at startup to carry out the mounting without user interaction.
Hello, it seems that GIO should handle your case as it is similar to mounting e.g. a NTFS partition in Nautilus — in both cases you don't have an fstab or crypttab entry. GIO discovers new devices and mounts them but I don't know much on existing ones at login, maybe we should move this bug there. As a workaround instead of udiskctl you can use "gio mount -d DEVICE" which takes care of the keyring for LUKS.
Hi, Thanks for your reply, but I'm not sure why it's marked as NEEDINFO? What additional information would you like me to provide about the issue? I filed the bug here because the gnome-disks utility had an option to "unlock at startup", which it failed to do for a normal user with credentials stored in gnome-keyring. If the bug belongs elsewhere, I'd be happy to refile it, please just let me know where it should go...
Hi, sorry to be confusing for you, I should explain it: The option presented in gnome-disks results in a crypttab entry, so this relates only to system startup (password prompt in initramfs) is not session login. I think that's not what you want, but more the behavior of having "gio mount -d DEVICE" in your .config/autostart, right? Then the encryption settings for the device should be just left in "automatic mode" in gnome-disks. I wanted to write GVfs instead of GIO and that's where I the discovery and mounting of new devices in the session happens. So I suppose we refile it to GVfs in order to look if there can be an unlock of devices directly after startup. Regards, Kai
Ah, thanks for clarifying that. Yes, I'm not after a crypttab entry, but one that triggers on user login. I believe gio mount would achieve this, but it seemed as though gnome-disks was the utility to use for mounting disks by users, and I didn't manage to discover the gio command during my searches at the time. Perhaps the documentation for udisks could point more heavily towards gio for automatic mounting (and clarify that "unlock at startup" means system startup rather than session startup)?
Created attachment 351397 [details] [review] Clarify meaning of encryption/mounting options Thanks for caring instead of finding an individual solution and then forgetting the problem ;) I suggest this patch with (a bit clunky) clarification of the mount and encrypt option dialogs.
My pleasure, thanks for answering a ticket I thought had fallen by the wayside! 5:) I don't know if was me you wanted to look over the patch, but the additions of "system startup" make sense. I'm not sure that the options marked "user session" actually do relate to the user session though?
The idea was a) to distingush the mount handling in the user session from the system wide set up in /etc/fstab and b) to make clear that it depends on the session to do mount handling (e.g. GVfs in GNOME session) and if nothing happens in other sessions then gnome-disks can't help. Mike, do you want to file the bug to GVfs or should I do it? https://bugzilla.gnome.org/page.cgi?id=browse.html&product=gvfs Ondrej or Michael, does one of you want to review it?
Ok, I see. It's a little bit confusing to have some system options in a dialog that's heading mentions user session stuff, but I understand the reason for making the separation clear for the user side now. I'm not entirely sure what I'd be asking of the GVfs people, so if you're happy to file it I'd appreciate it. If not, then I'd probably just file a tweaked version of the initial issue report for this bug. Please let me know either the new bug number, or if you'd prefer me to do it. Thanks! 5:)
Hm, I'm not sure - I can't reproduce it but have the suspicion that it depends on the device access: do you need to enter your administrative password? I tried this on Fedora Rawhide: unmount/lock device, log out and kill all remaining user processes, log in again and there it was unlocked and mounted.
It was a year ago, and since then I've changed my laptop (and am now using hardware disk encryption). Previously the drives showed up in the sidebar of nautilus, and on clicking them they were mounted (using my credentials). I think I might have had to change the polkit rules to allow mounting by the current seat rather than requiring administrative privileges. Nautilus changed and the sidebar no longer listed additional drives on the sidebar, which led me in search of getting them unlocked automatically (and I ended up at gnome-disks/udisks). So basically, at the time I think I couldn't get udisks to mount the drives automatically, but I could click play/mount in gnome-disks and it mounted fine (but was an irritating additional step). That suggests that requiring administrative access wasn't the issue, but simply that the disks weren't be checked at user login. It might well have been fixed in the versions since I filed this. If the fedora version is unlocking drives automatically at user login (from the credentials in the user's keyring, so without any crypttab entries), then I'm happy to have this issue closed...
(In reply to Kai Lüke from comment #7) > The idea was a) to distingush the mount handling in the user session from > the system wide set up in /etc/fstab and b) to make clear that it depends on > the session to do mount handling (e.g. GVfs in GNOME session) and if nothing > happens in other sessions then gnome-disks can't help. > > Mike, do you want to file the bug to GVfs or should I do it? > https://bugzilla.gnome.org/page.cgi?id=browse.html&product=gvfs There is not need to file a bug report for GVfs since I am more-or-less the only maintainer of it and monitor also Gnome Disks' bugs currently... > Ondrej or Michael, does one of you want to review it? Will look...
(In reply to Mike Auty from comment #10) > It was a year ago, and since then I've changed my laptop (and am now using > hardware disk encryption). Previously the drives showed up in the sidebar > of nautilus, and on clicking them they were mounted (using my credentials). > I think I might have had to change the polkit rules to allow mounting by the > current seat rather than requiring administrative privileges. All shown devices should be automounted by gnome-shell by default. It seems that automounting is disabled in your case. What is output from the following? gsettings get org.gnome.desktop.media-handling automount You can try to enable automounting by the following if the previous command returns false: gsettings set org.gnome.desktop.media-handling automount true > Nautilus changed and the sidebar no longer listed additional drives on the Only the hotplugged devices are in the sidebar recently, however, the devices in "Other Locations" tab should be automounted anyway... > sidebar, which led me in search of getting them unlocked automatically (and > I ended up at gnome-disks/udisks). So basically, at the time I think I > couldn't get udisks to mount the drives automatically, but I could click > play/mount in gnome-disks and it mounted fine (but was an irritating > additional step). That suggests that requiring administrative access wasn't > the issue, but simply that the disks weren't be checked at user login. It > might well have been fixed in the versions since I filed this. > > If the fedora version is unlocking drives automatically at user login (from > the credentials in the user's keyring, so without any crypttab entries), > then I'm happy to have this issue closed... I've made a simple test and it seems it works correctly on Fedora for me also. What is your distribution?
(In reply to Ondrej Holy from comment #12) > All shown devices should be automounted by gnome-shell by default. It seems > that automounting is disabled in your case. What is output from the > following? > gsettings get org.gnome.desktop.media-handling automount It is true on my current laptop, but as I mentioned this issue was from a year ago and a previous machine. > > Nautilus changed and the sidebar no longer listed additional drives on the > > Only the hotplugged devices are in the sidebar recently, however, the > devices in "Other Locations" tab should be automounted anyway... The encrypted partitions in Other Locations were not being automounted (nor did they automount back when nautilus did display them in the sidebar, since I always had to click them in nautilus to get them unlocked). Again, I'm unable to test that these days since I've swapped out my hard disk for one that does full disk encryption in hardware, and have no software LUKS partitions that can be user mounted. > I've made a simple test and it seems it works correctly on Fedora for me > also. What is your distribution? I am (and was) using Gentoo. If encrypted partitions are getting automounted on user login without need for a crypttab, then I'm happy to have this ticket marked as resolved.
Review of attachment 351397 [details] [review]: Thanks for the patch! To be honest, I am not really good at string changes. This is usually good to discuss with designers. However... ::: src/disks/ui/edit-crypttab-dialog.ui @@ +90,3 @@ <property name="visible">True</property> <property name="can_focus">False</property> + <property name="label" translatable="yes">_Automatic Encryption Options of User Session</property> The label seems too complicated to me. Wouldn't be enough to just change the tooltip and let the label untouched? The tooltip describes that the options relates to crypttab file, so you can add one more sentence about that user session options are used in other cases. The same applies for fstab dialog. @@ +302,3 @@ <child> <object class="GtkCheckButton" id="crypttab-neg-noauto-checkbutton"> + <property name="label" translatable="yes">_Unlock at system startup</property> This looks ok, same applies for fstab dialog.
Thanks for your feedback, I haven't realized that the report is one year old. Anyway, let's reopen the bug in order to deal with the proposed patch...
Created attachment 351424 [details] [review] Clarify meaning of encryption/mounting options Thanks for the feedback, I suggest calling the switch just "user session defaults" if "automatic mounting" is unspecific (when does it mount?) and also can't guarantee it.
Review of attachment 351424 [details] [review]: Looks good to me.
(how do I set the patch status?)