4:09 p.m.
Hi Rich and Pino,
Commenting after a test. I've installed a RHEL 7 virtual machine with 2
disks, using the graphical installer. During the installation, I selected
the 2 disks as well as encryption checkbox. It asked me for only one
password.
After the installation, when the machine boots, it asks for the password
(showing a device UUID) only once. When connected as root, I can see that
there are indeed 2 encrypted partitions: /dev/sda2 and /dev/sdb1, which are
used as LVM PVs.
They both use the same encryption key, but the initramfs only prompts once,
which is the behavior proposed by Rich.
So, I pushed the test a little more and added 2 disks to the virtual
machine and manually configured LUKS (luksFormat, etc...), with the same
passphrase, but different from the one provided during the installation.
I added the disks to /etc/crypttab and at boot I'm asked to provide 3
passphrases: 1 for the initial devices and 1 per additional disk. This is
similar to Pino's fully deterministic approach.
I then realized that I had encrypted the whole device, while the
installation had created partitions. So, I added 2 other disks and
partitioned them and encrypted them with the same passphrase, but a 3rd
one. This time, I'm asked for 5 passphrases, confirming that it doesn't try
the passphrase against more than one device.
But that doesn't explain why it asks for only one passphrase for the
initial devices. The LVM VG is configured with 2 PVs: /dev/sda2 and
/dev/sdb1. Maybe it's considered as a single unit. I would need to dig
deeper, but it's late.
So, the conclusion is that in the real world, we find both cases: 1 key for
multiple devices with a single prompt, and 1 identical key for multiple
devices with N prompts.
@Richard W.M. Jones <rjones(a)redhat.com>, do you think it's possible to add
the ability to provide the UUID instead of /dev/sdxN ? We could document
that the list of devices and UUIDs can be retrieved from lsblk and blkid.
My 2 cents.
On Tue, Nov 26, 2019 at 5:44 PM Richard W.M. Jones <rjones(a)redhat.com>
wrote:
You can specify default keys which are tried against each device
(after more specific keys fail), eg:
tool --key :key:defaultkey1 --key :key:defaultkey2
which would try "defaultkey1" and "defaultkey2" against all devices
in the guest.
---
options/keys.c | 3 ++-
options/options.h | 5 ++++-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/options/keys.c b/options/keys.c
index 782bdb6..817508b 100644
--- a/options/keys.c
+++ b/options/keys.c
@@ -148,7 +148,8 @@ get_keys (struct key_store *ks, const char *device)
for (i = 0; i < ks->nr_keys; ++i) {
struct key_store_key *key = &ks->keys[i];
- if (STRNEQ (key->device, device))
+ if (STRNEQ (key->device, "") &&
+ STRNEQ (key->device, device))
continue;
switch (key->type) {
diff --git a/options/options.h b/options/options.h
index 510e8a8..2f6bc5c 100644
--- a/options/options.h
+++ b/options/options.h
@@ -105,7 +105,10 @@ struct mp {
/* A key in the key store. */
struct key_store_key {
/* The device this key refers to. There may be multiple matching
- * devices in the list.
+ * devices in the list. It is never NULL but it may also be ""
+ * which is interpreted as a default key which is tried after any
+ * device-specific keys (there may be multiple defaults in the
+ * list).
*/
char *device;
--
2.23.0
_______________________________________________
Libguestfs mailing list
Libguestfs(a)redhat.com
https://www.redhat.com/mailman/listinfo/libguestfs
--
Fabien Dupont, RHCA
Principal Software Engineer
Red Hat - Migration Engineering <https://www.redhat.com>
<https://red.ht/sig>
<https://redhat.com/summit>