10:18 a.m.
Hi,
for <https://bugzilla.redhat.com/show_bug.cgi?id=1658126>;, I'll soon
post four short patch sets in response to this email (I'm sending this
email basically as a common cover letter for those sets, for better
threading).
The main difference (for libguestfs & co) between LUKS-on-LVM and
LVM-on-LUKS is that in the latter, the names of the decrypted LUKS block
devices don't matter. However we name the decrypted devices via
inspect_do_decrypt() -> make_mapname() in "common/options/decrypt.c" is
irrelevant, as LVM will scan for PVs on all block devices, regardless of
their names. The resultant LVs (hosting the filesystems) are what
"/etc/fstab" refers to, and we can deal with those names -- the VG and
LV names -- well, because (a) there is an "lvs" command (and API) for
enumeration (see "lv_canonical" in "daemon/lvm_utils.ml", and
lv_canonical() in "daemon/lvm.c" -- see also commit c37c8e770d664), and
(b) the VG and LV names are stored in the LVM metadata, so libguestfs
doesn't have to "invent" names.
This is not the case with LUKS-on-LVM. The names of the decrypted LUKS
devices is relevant, as they directly host filesystems, and "/etc/fstab"
likely refers to them. Furthermore, there is no enumeration / scanning
inside the guest, only a file called "/etc/crypttab". Unfortunately, the
root filesystem containing "/etc/crypttab" tends to exist on a LUKS
device as well, so we can't consult it for determining the decrypted
device names when we're about to decrypt those same devices in
inspect_do_decrypt(). (This circular dependency is circumvented during
normal guest boot by having a plaintext initrd containing a copy of
"/etc/crypttab", and LUKS-related parameters on the a kernel command
line in the bootloader config.)
In fact, since at least RHEL6, when the user selects either LVM-on-LUKS
or LUKS-on-LVM in Anaconda, the installer never asks for LUKS device
names (while it does let the user set VG and LV names). Instead, for a
given LUKS header containing UUID <UUID>, the decrypted block device
will automatically be named /dev/mapper/luks-<UUID>. (Anaconda sets up
"/etc/crypttab" and "/etc/fstab" like that.)
The patches I'm about to post follow the same logic -- I don't attempt
intricate UUID-based (re)mappings through "/etc/crypttab", in
"check_fstab_entry" -> "resolve_fstab_device", in
"daemon/inspect_fs_unix_fstab.ml".
(Assume that "/etc/fstab" refers to "/dev/mapper/hunter2" as a
plaintext
block device to mount.
Assume that "/etc/crypttab" associates the "hunter2" device name with
a
block device containing a LUKS header with UUID
28372dec-afca-412a-a089-736437fd03af. (For us to realize this, we'd need
to parse "/etc/crypttab" with Augeas in the first place.)
Then we'd have to recall, by UUID, that we had mapped that particular
LUKS device as "/dev/mapper/crypt<WHATEVER>" in inspect_do_decrypt().
Then either close and reopen the LUKS device as "hunter2" (there is no
rename operation!), which could get messy as the dependent filesystem
would be in use, or replace "hunter2" with "crypt<WHATEVER>" in
both
"/etc/fstab" and "/etc/crypttab".)
Instead, accept the "/dev/mapper/luks-<UUID>" naming scheme as the
standard one. Thus, inspect_do_decrypt() will name the decrypted block
device "/dev/mapper/luks-<UUID>" at once (rather than
"/dev/mapper/crypt<WHATEVER>"). And that name is expected to match the
references in "/etc/fstab" and "/etc/crypttab".
I've tested this with RHEL-6 and RHEL-7 guests successfully (using
"guestfish -i", "virt-inspector", and virt-v2v). Example
"lsblk"
outputs, with "lsblk" executed in the converted domains:
RHEL6:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 252:0 0 20G 0 disk
├─vda1 252:1 0 500M 0 part /boot
└─vda2 252:2 0 19.5G 0 part
├─vg_rhel6luks-root (dm-0) 253:0 0 14.7G 0 lvm
│ └─luks-0d619854-ccd5-43b1-8883-991fec5ef713 (dm-2)
253:2 0 14.7G 0 crypt /
└─vg_rhel6luks-swap (dm-1) 253:1 0 4.9G 0 lvm
└─luks-4e9e7a6f-a68c-42fd-92b4-8f4f2579a389 (dm-3)
253:3 0 4.9G 0 crypt [SWAP]
RHEL7:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 252:0 0 20G 0 disk
├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 19G 0 part
├─rhel_rhel7luks-root 253:0 0 10G 0 lvm
│ └─luks-74558d73-1ef3-4327-878b-f11b266a20fc 253:3 0 10G 0 crypt /
├─rhel_rhel7luks-swap 253:1 0 3.9G 0 lvm
│ └─luks-621270fd-6758-4001-8335-492cf5e32a45 253:2 0 3.9G 0 crypt [SWAP]
└─rhel_rhel7luks-home 253:4 0 5.1G 0 lvm
└─luks-0433f315-afd7-41a0-bd94-3f742114035c 253:5 0 5.1G 0 crypt /home
Thanks,
Laszlo