Can't input password with keyscript=decrypt_keyctl in initramfs

Bug #1362881 reported by Marek Dopiera
34
This bug affects 6 people
Affects Status Importance Assigned to Milestone
cryptsetup (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Setup
---
Description: Ubuntu 14.04.1 LTS
Release: 14.04

cryptsetup:
  Installed: 2:1.6.1-1ubuntu1
  Candidate: 2:1.6.1-1ubuntu1
  Version table:
 *** 2:1.6.1-1ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
        100 /var/lib/dpkg/status

My root device is luks-encrypted LVM volume. I have several other devices encrypted with the same password, so I wanted to use keyscript=decrypt_keyctl option in crypttab not to enter the password several times. The problem is that while in initramfs, I cannot enter the password (the terminal doesn't react to anything after it prompts for password).

Reason for failure
---
I debugged the problem myself and the reason is:
- plymouthd is running and grabbing all the input
- dekrypt_keyctl script uses askpass for password, so it doesn't get any input

Solution
---
The solution is to make the script plymouth-aware. I attach a patch which solved the issue for me.

Comment
---
The problem is deeper though - any keyscript needs to be plymouth-aware. I think what we can be done is the manpage updated - if plymouth is used (default) and the scrupt requires any input, it needs to be done via plymouth.

Workaround
---
I tried chmod -x /sbin/plymouthd as a workaround, but didn't fix the problem:
-plymouth scripts in init-top and init-bottom failed (that's probably fine, except they should not emit any error messages)
-I was able to decrypt the root device in initramfs
-for some reason (I didn't dig more) devices which did not have the keyscript set failed to be decrypted (prompt was displayed, but when I entered the password it was echoed to the console, devices were not decrypted and the init process stuck)

I does fix the problem if all the devices share the same key and all have the script set though.

Tags: patch trusty
Revision history for this message
Marek Dopiera (3z-marek-2q) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "decrypt_keyctl.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

tags: added: patch
tags: added: trusty
Revision history for this message
bastafidli (ubuntu-bastafidli) wrote :

First of all I had to install package keyutils as described in following Debian bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735496
to make update-initramfs work

Second of all, the patch doesn't seem to work for me. Plymouth asks me to cache passphrase for every one of my encrypted disks.

Revision history for this message
Sebastian (da-sh) wrote :

I can confirm the bug still exists in Ubuntu 14.04.2 LTS desktop. I used the encryption setup from the Ubuntu installer, and then wanted to decrypt a second drive /dev/sdb with the same password.

When I used the default decrypt_keyctl script, I would not see a prompt and would not be able to continue the boot process, so I believe this bug can cause serious trouble for users.

I modified /lib/cryptsetup/scripts/decrypt_keyctl as in the patch suggested by Marek.
Then, I can use the following settings in /etc/crypttab:
    sda3_crypt UUID=123 group1 luks,discard,keyscript=decrypt_keyctl
    sdb_crypt UUID=456 group1 luks,discard,keyscript=decrypt_keyctl

Afterwards, I ran
    sudo update-initramfs -u

Now, I need to type the password only once. I can either type the password directly or login via SSH (I installed dropbear and busybox).

Thank you, Marek!

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in cryptsetup (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.