[Bug 595648] Re: Remote unlocking not possible if plymouth is active (Bug or Feature?)

[Richard Hansen]

The /scripts/local-top/cryptroot script in the initramfs only unlocks
the root and resume filesystems.  All other encrypted filesystems are
unlocked by /etc/init/cryptdisks-udev.conf and /etc/init/cryptdisks.conf
after the real / has been mounted.

This design is problematic for remote unlocking:  If one of those non-
root non-resume encrypted filesystems is essential to booting the system
(it has the 'bootwait' option in /etc/fstab), then the initramfs will go
away before the filesystem is unlocked (because the root filesystem is
mounted), but sshd won't start because it's waiting for another
essential filesystem to be unlocked.  Thus, there's no way to remotely
access the system and unlock the remaining filesystem(s).

Before this bug can be considered fixed, /usr/share/initramfs-
tools/hooks/cryptroot will have to be edited to include all 'bootwait'
filesystems in the /conf/conf.d/cryptroot config file it produces in the
initramfs.

As a temporary workaround, users can add non-root non-resume 'bootwait'
filesystems to /etc/initramfs-tools/conf.d/resume as if they were resume
devices, though they must be listed BEFORE the real resume device.
(/usr/share/initramfs-tools/hooks/cryptroot can handle multiple RESUME=*
lines, and the initramfs init script ignores all RESUME=* lines but the
last.)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to cryptsetup in Ubuntu.
https://bugs.launchpad.net/bugs/595648

Title:
  Remote unlocking not possible if plymouth is active (Bug or Feature?)

Status in “cryptsetup” package in Ubuntu:
  Triaged
Status in “plymouth” package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: cryptsetup

  If plymouth is active, it is no longer possible in an easy way to remotely unlock the disc(s).
  Which means that with a standard Ubuntu setup the README.remote is wrong or incomplete.

  Reason: Plymouth is "stealing" the password prompt because the
  cryptroot script checks if plymouth is active:

  if [ -z "$cryptkeyscript" ]; then
  			cryptkey="Unlocking the disk $cryptsource ($crypttarget)\nEnter passphrase: "
  			if [ -x /bin/plymouth ] && plymouth --ping; then
  				cryptkeyscript="plymouth ask-for-password --prompt"
  				cryptkey=$(echo -e "$cryptkey")
  			else
  				cryptkeyscript="/lib/cryptsetup/askpass"
  			fi
  		fi

  but only askpass has a feature which is checking for a file with a
  password in it.

  Because I am not so good in writing startup fixes, I am proposing this as a bug.
  Possible solutions:
  1. Include a new script, which doesn't use plymouth at all.
  2. Use command line switches to use askpass instead of plymouth.
  3. Patch plymouth, e.g. to include a "pass-as-password" option, which is passing the password along to a running plymouth(d?).

  My knowledge about the inner workings of the startup process is limited, I would prefer solution no. 3.
  Any suggestions?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/595648/+subscriptions