When mounting encrypted drives the password should be asked for graphically and not in text mode

Bug #110970 reported by Nicholas Allen on 2007-04-29
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Leandro Pereira de Lima e Silva

Bug Description

My home drive is an encrypted LUKS partition. When it is mounted during boot upstart switches from a graphical boot splash screen to the terminal where it asks me for the password. It then continues to boot in text mode.

It works but this looks seriously tacky! It would be nice if there was a utility that could ask for the password graphically when upstart is running so that the user never leaves graphical boot screen. It would add a lot of polish to the end user experience...

This has nothing to do with upstart

Changed in upstart:
status: Unconfirmed → Rejected
Kjell Braden (afflux) wrote :

This is definetly annoying.

Changed in cryptsetup:
status: New → Confirmed
Tony Yarusso (tonyyarusso) wrote :

Confirming, with some additional details:

I have encrypted both my /home and swap, using the new options directly in the installer in Gutsy. On boot, the passphrase for swap is correctly asked within the context of usplash, and the boot continues graphically. However, when the time comes to boot /home, it breaks usplash and drops to text-mode as described. After inputting the passphrase, boot continues in text-mode.

Additionally, it should be noted that in the usplash prompt for swap, is specifies the volume the passphrase is being requested for (in my case embarrass-swap_crypt), but at the text mode prompt it simply says "Enter LUKS passphrase" (iirc), with NO indication anywhere on the screen of what volume it is for. If a use had encrypted more volumes than just swap and /home, they would therefore have to either a) be using the same passphrase for all volumes, or b) have memorized the order of mounting in the boot sequence.

Reinhard Tartler (siretart) wrote :

as long as usplash doesn't provide sensible input mechanisms for passwords, I'd vote against such a change.

In fact, I once wrote a patch implementing this, uploaded it to edgy (or feisty?), and then replaced it with the current patch which terminates usplash if it is running.

Hamish Downer (mishd) wrote :

On my hardy install, I am asked for my password in graphical mode. (I have an unencrypted boot partition, and the other partitions are in an encrypted logical volume, installed using the alternative install disk).

So if someone else can confirm this is the case for other encrypted set ups (at least for fresh installs of hardy) then I guess this bug should be marked as "fix released" and closed.

Christoph (christop) wrote :

I think this works since Gusty, at least it is working now in Hardy.

Reinhard Tartler (siretart) wrote :

it does work from the initramfs hook, e.g. for unlocking LUKS encrypted LVM volumes. It does switch to text mode when unlocking from the init scripts. this is e.g. the case with an encrypted home partition on an unencrypted root.

same Problem here on a HP 6510b (with Hardy)

Florent (florent.x) wrote :

same problem: swap unlocked graphically, while other partition (/var) unlocked in text mode.

I resolved the issue by forcing initramfs to decrypt all partitions in a row.

See the new patch attached on bug #139057.

I've written a patch to one of cryptsetup package scripts so it uses usplash to ask the password.

The file: /lib/cryptsetup/cryptdisks.functions

The patch is attached. Try it out please. It's working here.

Changed in usplash:
status: New → Invalid
Changed in cryptsetup:
status: Confirmed → In Progress

Oh, I'm also attaching the complete script for the ones that doesn't know how to patch a file.

File: /lib/cryptsetup/cryptdisks.functions

Reinhard Tartler (siretart) wrote :

please always assign a bug to you if you are working on it.

Changed in cryptsetup:
assignee: nobody → leandro-limaesilva
Launchpad Janitor (janitor) wrote :
Download full text (5.6 KiB)

This bug was fixed in the package cryptsetup - 2:1.0.6-6ubuntu1

cryptsetup (2:1.0.6-6ubuntu1) intrepid; urgency=low

  * drop almost all ubuntu specific changes from the cryptsetup package,
    because they have been merged in debian. Thanks a lot!
  * merge from debian, remaining changes:
    - remove versioned build-depency on libdevmapper-dev, we are using a
      rather sophisticated loop for making sure the root filesystem appears.
  * debian/rules: fix location of ltmain.sh
  * don't exit usplash anymore in the init script. LP: #110970, #139363
  * Disable error message 'failed to setup lvm device'. It is harmless, and
    caused by the fact that the udev rules provided by lvm2 are setting up
    the lvm on their own. In debian the scripts here are responsible for this
    but obviously fail in ubuntu. LP: #151532

cryptsetup (2:1.0.6-6) unstable; urgency=high

  * Don't cat keyfile into pipe for do_noluks(). cryptsetup handles
    --key-file=- different for luks and plain dm-crypt mappings. This time
    really (closes: #493848). Thus again upload with urgency=high.

cryptsetup (2:1.0.6-5) unstable; urgency=high

  * Fix watch file to not report -pre and -rc releases as superior.
  * Remove the global var $SIZE from cryptdisks.functions again but keep the
    extended value checks.
  * Remove the udev rules file also in preinst, code taken from example at
    http://wiki.debian.org/DpkgConffileHandling. Thanks Marco d'Itri.
    (closes: #493151)
  * Remove duplicated configuration of --key-file in $PARAMS at do_noluks().
    (closes: #493848).
  * Invoke mount_fs() and umount_fs() in cryptdisks_start, add
    log_action_begin_msg() and log_action_end_msg() to both cryptdisk_start
    and cryptdisks_stop.
  * Copy fd 3 code from do_start and do_stop to cryptdisks_start and
    cryptdisks_stop to fix "keyscript | cryptsetup". (closes: #493622)
  * This upload fixes two RC bugs, thus upload with severity=high.

cryptsetup (2:1.0.6-4) unstable; urgency=medium

  [ David Härdeman ]
  * Make sure $IGNORE is reset as necessary, patch by Thomas Luzat
    <email address hidden> (closes: #490199)
  * Use askpass in init scripts as well (closes: #489033, #477203)

  [ Jonas Meurer ]
  * Don't copy_exec libgcc1 in cryptopensc initramfs hook, as it's already
    copied by copy_exec /usr/sbin/pcscd automaticly. Thanks to Evgeni Golov
    <email address hidden>. (closes: #490300)
  * Remove the udev rules file again as the relevant rules are now provided
    by dmsetup package which cryptsetup depends on.
  * Add splashy support to askpass, thanks to John Hughes <email address hidden>
    for the patch. (closes: #492451) The support is limited to cryptroot
    though, as splashy freezes for passphrase input dialogs from initscripts.
    Document that in README.Debian.
  * Now that askpass is used as keyscript for interactive mode, it's not
    necessary to set cryptsetup parameter '--tries=$TRIES' and TRIES=1 for
    interactive mode anymore in cryptdisks.functions.
  * Implement special treatment for random passphrases now that we use
    "--key-file=-" for all situations. Only necessary in do_noluks.
  * Fix the passphrase prompt string in...


Changed in cryptsetup:
status: In Progress → Fix Released
Saivann Carignan (oxmosys) wrote :

Reinhard Tartler : Your fix introduces more important bug, including a security issue. Please read the discussion in bug 139363 . Please consider reverting your changes or use another fix for these reasons :

Password echoed in plain text in console : usplash prompt has been already tested in the past, and there is a reason why it has not been used. When typing your password in usplash prompt, your password is echoed in plain text in the console. If you read the cryptsetup changelog, you'll see that this issue happened in the past and that's why developers choosed to break usplash instead. I can reproduce this security problem with your current package in intrepid. You can see more information in bug 55159, read my last comment on that bug.

fsck fill cryptsetup prompt : if fsck runs before usplash cryptsetup prompt, it will fill your prompt with fsck outputs. This is impossible to type your password in these conditions, and a unclean reboot takes you to the same point since fsck starts again.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers