daemon-reload in running system can result in prompt for cryptoswap passphrase
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd (Ubuntu) |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
This is an extremely odd bug that requires a very specific scenario to reproduce:
1) You need to be using an ecryptfs-style cryptoswap partition (as would be setup when you choose "Encrypt my home directory" during the installation)
2) The underlying physical swap partition used for the cryptoswap needs to be on a GPT partitioned drive
3) The GUID specific bit 63 ("no auto mounting") must *not* be set on the underlying physical swap partition
In this scenario, installing/
For example, if you have the needed setup, you can easily reproduce this bug with:
sudo apt-get install --reinstall whoopsie
After which you'll encounter something like this:
(Reading database ... 177827 files and directories currently installed.)
Preparing to unpack .../whoopsie_
Please enter passphrase for disk primary (cryptswap1) on none!
Unpacking whoopsie (0.2.52.1) over (0.2.52) ...
Preparing to unpack .../libwhoopsie
Unpacking libwhoopsie0:amd64 (0.2.52.1) over (0.2.52) ...
Processing triggers for systemd (229-4ubuntu6) ...
Processing triggers for ureadahead (0.100.0-19) ...
ureadahead will be reprofiled on next reboot
Processing triggers for libc-bin (2.23-0ubuntu3) ...
Setting up libwhoopsie0:amd64 (0.2.52.1) ...
Setting up whoopsie (0.2.52.1) ...
Please enter passphrase for disk primary (cryptswap1) on none!
Processing triggers for libc-bin (2.23-0ubuntu3) ...
(You can just hit enter each time the "Please enter passphrase for..." prompt comes up.)
For some background: in modern systemd times, ecryptfs-style cryptoswaps are broken when the underlying physical GPT swap partition does not have bit 63 set:
https:/
During the boot the user is erroneously prompted for a passpharase to unlock the cryptoswap (you can hit enter for an empty passphrase, or enter any passphrase you want... either way, nothing seems to actually be done with it). After the boot completes, the underlying physical swap partition will be mounted normally (ie, you wont actually be using encrypted swap... so a false sense of security, which is of course concerning).
Although lp:1447282 has been fixed for the most common hardware configurations, it's still possible for users to encounter this problem in the real-word: ecryptfs-setup-swap currently fails to set bit 63 when the physical GPT swap partition is on an NVMe or MMC drive:
https:/
So one way to reproduce this is to install Ubuntu 16.04 onto an NVMe drive and choose "Encrypt my home directory" during the installation.
To make debugging this easier without requiring an NVMe drive (and especially so it's easier to debug in a UEFI VM), I'm attaching a script that will unset bit 63 on the underlying GPT swap partitions used by any ecryptfs-style cryptoswaps that are present.
If you run my script:
sudo python3 unset-bit-63.py
And then reboot, you should now be able to reproduce this bug.
Even though fixing lp:1597154 will mean users shouldn't encounter (during normal real-world usage) this strange behavior when installing/
Thanks!
Also attaching a screenshot, just so folks don't think I'm making this up :P