So unfortunately /etc/crypttab is not a viable workaround, because it tries to mount the partition also on boot (when it's not there), which makes the boot 10 seconds longer.

David, doesn't /etc/crypttab work for this ?

See comment 1. Moreover, I would prefer the password to be stored in Gnome keyring, as it was before. If I put the password in a system-wide config file, any user that connects my external HDD to that computer can read my encrypted partitions. No, thanks :)

Reassigning to gvfs as the fact that we no longer offer to store the LUKS password in the user's keyring is because of gvfs' udisks2 volume monitor.

Whether we should store the passphrase in the users keyring (and try to use it when mounting the device) is an interesting question.

We currently don't do this because, as mention, you can use /etc/crypttab for this ... of course, as comment 3, says, it won't work on a shared system (and it's also really only effective if you used encrypted /etc).

The main reason for this is really this: if you want to automatically unlock+mount a device, it's probably not a shared system (ie. it's your laptop). If it's a laptop, then you probably use encrypted root (to avoid ). Therefore, it's fine to use the crypttab approach.

The other reason is that being able to store the key in both the keyring and crypttab is confusing - you now have two keystores that you can confuse the user. It would confuse the UI in Disks.

My use case: Yes, it's a laptop, it has an encrypted root. But it is a shared system. I have several user profiles if my family/friends want to use it (provided it's running). But I don't want them to just connect my external HDD and access my private files.

That means /etc/crypttab is not usable for me. Also, I have not investigated further, but the system tries to look for that device on boot even though it's not present, making the boot longer and systemd marking that service as FAILED. I don't like red colors. /etc/crypttab seems to be suited for static disk setups, not for dynamic ones.

> Whether we should store the passphrase in the users keyring (and try to use it
> when mounting the device) is an interesting question.

GNOME 2 did that for years. It was working well. I used it, my father (Linux newbie) used it. Insert drive, type password, check 'remember', voila. Very intuitive. /etc/crypttab - not so much.

> The other reason is that being able to store the key in both the keyring and
> crypttab is confusing - you now have two keystores that you can confuse the
> user. It would confuse the UI in Disks.

/etc/crypttab will be configured only by system administrator. Gnome Keyring can be populated by ordinary users who have just a standard account on that system. Shared system doesn't mean insecure system. Storing disk password in an encrypted Gnome Keyring in a password-protected user account can be totally satisfactory for people (home computer, school computer). The current implementation doesn't offer any solution for shared systems.

(In reply to comment #6)
> My use case: Yes, it's a laptop, it has an encrypted root. But it is a shared
> system. I have several user profiles if my family/friends want to use it
> (provided it's running). But I don't want them to just connect my external HDD
> and access my private files.

Just use a fstab mount point that only your user can access. E.g. /mnt/myuser/disk where /mnt/myuser is mode 0700 and owned by you.

> That means /etc/crypttab is not usable for me. Also, I have not investigated
> further, but the system tries to look for that device on boot even though it's
> not present, making the boot longer and systemd marking that service as FAILED.
> I don't like red colors. /etc/crypttab seems to be suited for static disk
> setups, not for dynamic ones.

Use the 'nofail' options in crypttab and fstab.

> > Whether we should store the passphrase in the users keyring (and try to use it
> > when mounting the device) is an interesting question.
> 
> GNOME 2 did that for years. It was working well. I used it, my father (Linux
> newbie) used it. Insert drive, type password, check 'remember', voila. Very
> intuitive. /etc/crypttab - not so much.

Not true. You can use Disks to add crypttab and fstab entries to achieve automatic unlock+mount.

> The current implementation doesn't offer any solution for shared systems.

That's not accurate ... things still work very streamlined and the only difference, really, is that you will be prompted for the pass-phrase when you attach the device. Which in some way is actually more secure.

(In reply to comment #7)
> (In reply to comment #6)
> > My use case: Yes, it's a laptop, it has an encrypted root. But it is a shared
> > system. I have several user profiles if my family/friends want to use it
> > (provided it's running). But I don't want them to just connect my external HDD
> > and access my private files.
> 
> Just use a fstab mount point that only your user can access. E.g.
> /mnt/myuser/disk where /mnt/myuser is mode 0700 and owned by you.

In fact, in this case, it's enough to just add an /etc/crypttab entry for the device and the device will auto-mount on plugin. This is because we now mount stuff in /run/media/$USER/ which is private per-user, e.g.

 # mount|grep Sekrit
 /dev/mapper/luks-159b8908-9e6e-4dcd-9446-829462bc60f1 on /run/media/davidz/Sekrit type ext4 (rw,nosuid,nodev,relatime,seclabel,user_xattr,barrier=1,data=ordered,uhelper=udisks2)

 # getfacl /run/media/davidz/
 getfacl: Removing leading '/' from absolute path names
 # file: run/media/davidz/
 # owner: root
 # group: root
 user::rwx
 user:davidz:r-x
 group::---
 mask::r-x
 other::---

As I said, Disks has an easy way to add that crypttab entry, see

 http://people.freedesktop.org/~david/palimpsest2-2012-03/04-palimpsest2-edit-crypttab.png
 http://davidz25.blogspot.com/2012/03/simpler-faster-better.html

Bottom-line: all you *really* need to do to achieve automatic unlock+mount upon device insertion is

 1. Launch Disks, select the device in question
 2. Select "Edit Encryption Options..." from the gear menu
 3. Switch OFF "Automatic Encryption Options"
 4. Enter the password
 5. Click OK

and you are done. I don't think that's much worse than GNOME 2.

(In reply to comment #8)
> In fact, in this case, it's enough to just add an /etc/crypttab entry for the
> device and the device will auto-mount on plugin. This is because we now mount
> stuff in /run/media/$USER/ which is private per-user

So if Joe takes the external HDD from my shelf (no, I don't lock it up in a drawer) and connects it the to computer, my private partition unlocks for him.

Actually, Joe has his own encrypted partition on the same HDD. In the past (Gnome 2) I created encrypted partitions on that HDD for several people. They would just connect it and work with their files.

Custom mount points and entries in /etc/fstab could probably work, but I'm not going to try it, because that starts to be overly complicated, especially for several people on several computers. Typing the password once a week seems to be easier.

> As I said, Disks has an easy way to add that crypttab entry, see
> 
> 
> http://people.freedesktop.org/~david/palimpsest2-2012-03/04-palimpsest2-edit-crypttab.png
>  http://davidz25.blogspot.com/2012/03/simpler-faster-better.html

I always liked Palimpsest, it's great that there is now a simple interface to encrypt your (external) HDD. 

> 
> Bottom-line: all you *really* need to do to achieve automatic unlock+mount upon

As weird as it seems, I am really lazy and don't typing passwords. Gnome keyring encrypted with my login password is my best friend.

> device insertion is
> 
>  1. Launch Disks, select the device in question
>  2. Select "Edit Encryption Options..." from the gear menu
>  3. Switch OFF "Automatic Encryption Options"
>  4. Enter the password
>  5. Click OK
> 
> and you are done. I don't think that's much worse than GNOME 2.

That looks amazing, I just tried it. Unfortunately it fails my use case. But for permanently mounted drives this is superb, thank you for that.

I have failed to explain that I need a per-user solution, not a per-machine solution. I don't want Joe to unlock my partition when he connects the drive. I don't want to see Joe's password inside /etc. Also there are many environments where you trust the admins (that there are no keyloggers and such), so you want to save the password, but you don't have administrative access and you wouldn't even want your password saved in plaintext inside /etc, but gnome keyring used to be fine -> e.g. university computer, office computer or the shared home computer.

Anyway, your great work in Palimpses promises to bring a new army of users with encrypted (external) harddisks, working on shared computers, so I hope some of them will find this bug report and explain their/our use case better.

Thanks for all the feedback nonetheless.

This seems to go against the attempts to improve the user experience or improve security when using encrypted devices.  In this instance a user must always enter their password (not user friendly), or have a daemon running as root that writes shared configuration files for you (increased attack surface area, reveals password to all root privileged users), rather than using a system that's already in place and was designed to protect users' passwords on a per-user basis.

The arguments against reusing the existing system seem to be developer focused rather than user focused.  "Probably not a shared system, [...] probably use encrypted root, [...] therefore, it's fine to use the crypttab approach" has a number of issues with it.  Firstly, there's two separate assumptions in there, either of which makes using crypttab not fine, and even in the situations where it is fine, it may not be better than using gnome-keyring (and in fact, Kamil's described situations where it's both less user-friendly and less secure than using gnome-keyring).

As to causing confusion, there are many other user/machine configuration options out there, and they almost all work on a user > machine > default priority system.  Generally the user will not even be aware of the machine configurations, and if they are it will be because their machine administrator has specifically opted to change them.  Storing plain-text passwords in a file in /etc seems like such a step backwards for both security and usability.

Neither of the counter-arguments seems very strong, and the other solution was even present in the previous version, so is there some failing or downside of gnome-keyring that's brought about this change in the new one?

I talked a bit to Cosimo the other day about this

 - It's generally not a good idea to offer the user check-boxes
   when presenting a pass-phrase prompt. Also, a check-box is
   not really touch friendly. Cosimo had an idea of another way
   we could save the pass-phrase but I forget. Cosimo?

 - If the user does check "[x] Save pass-phrase in keyring" there is
   currently no way (except for seahorse) to remove the passphrase,
   change it or even find out that the pass-phrase is stored on his
   system

   However Cosimo mentioned bug 659043 where we could include a
   "forget pass-phrase" button in the proposed "Devices" tab of
   the "Details" part of the control center.

For the record, I still maintain that the whole "passphrase-less auto-unlock and auto-mount" use-case is pretty weird ... yes, I know all the arguments that you think your laptop is trusted and so on, that's not the point.

I haven't closed this bug WONTFIX because I still think we probably could add some level of gnome-keyring support. But I think it requires a bit more thinking and design than just blindly copying what GNOME 2 did (more specifically, what the hal/udisks2 volume monitors were doing).

>  It's generally not a good idea to offer the user check-boxes 
>  when presenting a pass-phrase prompt.

Fair enough, I'm not a UI designer and I don't have a problem with how password-saving is enabled as long as it's easily doable at the point where you might want to do it.

>  If the user does check "[x] Save pass-phrase in keyring" there is
>  currently no way (except for seahorse) to remove the passphrase,
>  change it or even find out that the pass-phrase is stored on his
>  system

I'm not sure I see the difference between this and the udisks model.  In both you have to visit a separate specific tool to find out if there's a password saved, and be able to change it or remove it.  Again though, I've no specific requirements on how this is implemented, just that it's possible.

> I still maintain that the whole "passphrase-less auto-unlock
> and auto-mount" use-case is pretty weird

It's not supposed to be passphrase-less auto-unlock, it's supposed to require the user's login password at login time, and then make it easy for them to mount/unmount as required.  It's precisely because the machine is shared and not strongly trusted that we want to protect the unlock passphrase with the user's passphrase, rather than leaving it unencrypted on the disk.

Thanks for not closing this off as WONTFIX.  If there's more design work to be done, please could you mark this as CONFIRMED and keep us updated on this bug so that it doesn't get forgotten about?

Here's my opinion.

Security is often a best effort kind of thing. To me is remembering a password on behalf of the user better than no encryption at all, or the user having to resort to writing it down on a paper, or worse, on the usb key itself? Definitely. (A friend related a story to me recently about how they handle encrypted USB keys at a local major hospital - yes they write the passphrase on the key itself)

I ask the computer to remember of lot of private things on my behalf. My gmail password, my credit card info, etc.

If someone has access to my unlocked account and possession of my computer and usb key (you need all three to get in: password, computer, disk). I'm not sure that the usb key is my biggest concern. If that key is indeed super sekrit and has launch codes on it or whatever perhaps we can have a way to lock things down so we force a prompt for every use. Or somehow use a two factor authentication which always implies a prompt of some kind. Or even have some bit that can be set on the key itself to hint that passprases should not be stored. We can also have a general lockdown key that tells GNOME not to store passwords (for kiosks etc).

As for where the data is stored, I think it is pretty clear it should be stored within the user's home directory. This makes it much easier to retain across updates, to backup, and to delete when necessary.

So, what I would prefer to see is that we save the passphrase by default. No checkbox. And allow the user to manage/remove/forget the credential in the Keyring management application - (more design work needed there I suspect).

In the event the phrase is changed on the key we should reprompt the user and explain that the stored passphrase did not work and to enter the new passphrase.

I strongly believe that we can only succeed when security is easy. Hope that helps.

FWIW, I agree with all of comment 13 except for automatically saving the passphrase without user consent (I'd like to have the checkbox). I'll see if I can find some cycles for 3.6.

What about to get some inspiration from Firefox?

1. User plugs in an encrypted device -> pop up a dialog asking for password

2. User provides correct password -> decrypt the device and pop up a dialog "Device decrypted, remember password?". Hide after few seconds. This is similar behavior Firefox uses for web passwords (make an offer, hide soon). Two successive pop-ups also seem to integrate well with Gnome Shell functionality.

3. If user changed his password using Disks utility -> automatically update password in gnome keyring

4. If user changed his password externally -> on next mount ask for password as usual (system knows the previous password failed) and again ask to remember the password. If confirmed, replace the old password with the new one in gnome keyring.

5. User wants to delete his password -> He/She needs to open Passwords and Keys tool, locate it and delete it. Again similar to Firefox.

Sounds pretty straightforward and similar to the workflow in other programs, doesn't it?

(In reply to comment #11)
> I talked a bit to Cosimo the other day about this
> 
>  - It's generally not a good idea to offer the user check-boxes
>    when presenting a pass-phrase prompt. Also, a check-box is
>    not really touch friendly. Cosimo had an idea of another way
>    we could save the pass-phrase but I forget. Cosimo?

I agree with many parts of comment #13 too, but not with the automatic saving of the password. I don't think it's OK to save my friend's password in the keyring by default just because he once plugged his key into my computer and unlocked his encrypted partition.

The way I see it, if you encrypt a device, it's fine to be asked for its password every time you plug it in by default (e.g. usually bank websites have the same policy).
What I was suggesting to you the other day is to decouple the act of saving the unlock password for a device from the act of plugging it in: no checkbox, no automatic saving, and provide a way of explicitly storing/forgetting the unlock password, either from the System Settings panel of bug 659043 or from the keyring management application, as suggested by Jon.

Alright, I've pushed the following patch

 http://git.gnome.org/browse/gvfs/commit/?id=79f0ea7c0d5cb39cf1ab40afaea0e485aeb4bc49

that adds keyring support so I'm closing this bug.

The shell still needs some work (for example, it doesn't support any of the "save in keyring" options in its GMountOperation) but Cosimo is aware of that - for now, just use nautilus if you want to save stuff.

OK, also committed a patch to Disks to also check the keyring

 http://people.freedesktop.org/~david/disks-luks-passphrase-from-keyring.png
 http://git.gnome.org/browse/gnome-disk-utility/commit/?id=a1d23726503212b0f5b1ce17153dea1e11c17235

*** Bug 673810 has been marked as a duplicate of this bug. ***

Thanks, David!

(In reply to comment #17)
> The shell still needs some work (for example, it doesn't support any of the
> "save in keyring" options in its GMountOperation) but Cosimo is aware of that -
> for now, just use nautilus if you want to save stuff.

Can you please explain this better? Do I understand correctly that gnome-shell popups have no support for saving password at the moment, but Nautilus does (by clicking on unmounted device)? There were no changes needed to be done for Nautilus?

Shouldn't we re-assign this bug to gnome-shell then, or at least create a new one?

What Cosimo, McCann and myself discussed yesterday was

 - gnome-shell's GMountOperation should be a modal dialog (instead of a
   notification) and we want it to also support GPasswordSave but probably
   default to G_PASSWORD_SAVE_PERMANENTLY and show it as a checkbox
   (e.g. ignore "never" or "save for session")

 - We want nautilus and the file chooser to also use the shell's
   GMountOperation ... we (probably) want to do this through a patch
   to GtkMountOperation so it just proxies to the shell if available
   and falls back to using a GtkWindow otherwise

(In reply to comment #21)
>  - gnome-shell's GMountOperation should be a modal dialog (instead of a
>    notification) and we want it to also support GPasswordSave but probably
>    default to G_PASSWORD_SAVE_PERMANENTLY and show it as a checkbox
>    (e.g. ignore "never" or "save for session")

Filed as bug 674962.

>  - We want nautilus and the file chooser to also use the shell's
>    GMountOperation ... we (probably) want to do this through a patch
>    to GtkMountOperation so it just proxies to the shell if available
>    and falls back to using a GtkWindow otherwise

Filed as bug 674963.

I can confirm Nautilus can now save partition password into gnome keyring. Great job.