[Touch-packages] [Bug 1597876] Re: installing/upgrading packages containing systemd services results in prompt for cryptoswap passphrase [xenial]
It's not that odd, this is a duplicate of bug 1447282. Installing
packages involves a lot of calls to "systemctl daemon-reload" which will
re-run the fstab generator and refresh the .mount units in /run. But I
suppose you filed that about asking this in a running system, not about
the wrongly marked swap partition (which really isn't a swap partition,
it's signature just looks like one).
** Changed in: systemd (Ubuntu)
Status: New => Triaged
** Summary changed:
- installing/upgrading packages containing systemd services results in prompt
for cryptoswap passphrase [xenial]
+ daemon-reload in running system can result in prompt for cryptoswap passphrase
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1597876
Title:
daemon-reload in running system can result in prompt for cryptoswap
passphrase
Status in systemd package in Ubuntu:
Triaged
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/upgrading/reinstalling seemingly *any*
package with a systemd service will result in the user getting *twice*
prompted for a passphrase to unlock their cryptoswap partition. If
upgrades are performed using the graphical Software Updater, the user
wont be aware of this issue unless they've expanded the details,
resulting in the Software Updater hanging indefinitely.
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_0.2.52.1_amd64.deb ...
Please enter passphrase for disk primary (cryptswap1) on none!
Unpacking whoopsie (0.2.52.1) over (0.2.52) ...
Preparing to unpack .../libwhoopsie0_0.2.52.1_amd64.deb ...
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://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1447282
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://bugs.launchpad.net/ecryptfs/+bug/1597154
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/upgrading/reinstalling packages that contain systemd
services, I have a strong hunch that the fact this can happen at all
indicates something is quite wonky in either systemd itself or in the
Debian/Ubuntu specific systemd trigger handling.
Thanks!
To manage notifications about this bug go to:
[Touch-packages] [Bug 1597876] Re: installing/upgrading packages containing systemd services results in prompt for cryptoswap passphrase [xenial]
Also attaching a screenshot, just so folks don't think I'm making this
up :P
** Attachment added: "screenshot.png"
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597876/+attachment/4692953/+files/screenshot.png
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1597876
Title:
installing/upgrading packages containing systemd services results in
prompt for cryptoswap passphrase [xenial]
Status in systemd package in Ubuntu:
New
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/upgrading/reinstalling seemingly *any*
package with a systemd service will result in the user getting *twice*
prompted for a passphrase to unlock their cryptoswap partition. If
upgrades are performed using the graphical Software Updater, the user
wont be aware of this issue unless they've expanded the details,
resulting in the Software Updater hanging indefinitely.
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_0.2.52.1_amd64.deb ...
Please enter passphrase for disk primary (cryptswap1) on none!
Unpacking whoopsie (0.2.52.1) over (0.2.52) ...
Preparing to unpack .../libwhoopsie0_0.2.52.1_amd64.deb ...
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://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/1447282
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://bugs.launchpad.net/ecryptfs/+bug/1597154
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/upgrading/reinstalling packages that contain systemd
services, I have a strong hunch that the fact this can happen at all
indicates something is quite wonky in either systemd itself or in the
Debian/Ubuntu specific systemd trigger handling.
Thanks!
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1597876/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
