found 768314 systemd/215-10
fixed 768314 systemd/218-8
retitle 768314 systemd: encrypted disk passphrase prompt nearly unusable
without plymouth
severity important 768314
thanks
Hi everyone,
after half a day of testing and reproducing I would like to summarize
this bug and add my own explanation:
Summary:
The way in which systemd queries for cryptsetup passwords is badly
usable in multiple ways. There are two main problems:
- Other output is not suppressed, which may overwrite or hide the
password prompt (except when plymouth io multiplexing is active)
- a 90 second startup timeout kills the password prompt after inactivity
For one disk, this is a slight usability problem. For multiple encrypted
volumes with longer passwords, it is a nightmare that makes using the
system annoying or impossible, often dropping to a rescue shell.
Steps to reproduce it without any special hardware:
- setup a simple debian jessie installation, unencrypted root+swap, no
LVM or fancy stuff
(e.g. in virtualbox, use snapshots for quickly rolling back after
testing something)
- apt-get install cryptsetup
- run the attached reproducer script as root. It sets up 3 crypto disks
from loopback files.
- reboot
test scenarios:
a) try to enter the password - it is "test" for each of the 3 disks
-> If you enter your password correctly, it works most of the time.
screen shot is attached, please note that the last two password prompts
are immediately overwritten by other messages.
b) just press enter randomly instead of typing a password
-> even the next password prompts will not be visible, but overwritten
by other messages!
c) just wait for >90sec
-> an emergency shell will be started and stopped, mixed with some
password prompts and "A start job is running for..."
-> if you wait even longer, the system will perform a weird dance
between "Give root password" and "Please enter passphrase for disk".
Test results:
Possible solutions and workarounds:
a) installing plymouth *and* enabling it by adding "splash" to the
default kernel commandline.
Just installing plymouth will not help here due to bug #768329 in
plymouth. If this were fixed we could add a dependency (recommends?) for
plymouth to systemd/jessie or cryptsetup/jessie as a dirty workaround.
b) systemd 218-8 from experimental
solves the underlying problems good enough so that I consider the bug as
fixed there:
- suppressing unnecessary output
- not having a timeout on password entry
For comparison, two screenshots are attached. In both I entered the
first two passwords and then made a screenshot at the password prompt
for the third disk. found-*.png is the problematic systemd version
currently in jessie, notfound-*.png the one in experimental.
Thanks
Max
-----
(Since I am not very familiar with the debian bug tracking system,
please remind me if I do something wrong.)
#!/bin/bash
set -e
echo -n test > /root/cryptPassphrase
num_disks=3
for i in `seq 1 $num_disks`; do
echo "cryptTest$i /root/cryptTest$i none luks" >> /etc/crypttab
echo "/dev/mapper/cryptTest$i /mnt/cryptTest$i ext4 defaults 0 0" >>
/etc/fstab
mkdir -p /mnt/cryptTest$i
fallocate /root/cryptTest$i -l 42M
cryptsetup --batch-mode luksFormat /root/cryptTest$i
/root/cryptPassphrase
cryptsetup luksOpen /root/cryptTest$i cryptTest$i
--key-file=/root/cryptPassphrase
mkfs.ext3 /dev/mapper/cryptTest$i
cryptsetup luksClose cryptTest$i
done
echo "now reboot. The crypto password is: test"
