Fedora – How to identify LVM-over-LUKS or LUKS-over-LVM

Depends on what the init script that asks the password of you is doing with it.

If it's systemd, it might just be a feature. systemd-ask-password comes with a cache functionality that might be responsible.

https://www.freedesktop.org/software/systemd/man/systemd-ask-password.html

--accept-cached

    If passed, accept cached passwords, i.e. passwords previously entered.

--multiple

    When used in conjunction with --accept-cached accept multiple passwords.
    This will output one password per line.

In this fashion it would first try the passwords you already entered, and only ask for another passwords if that didn't work.

The downside of such an idea is that checking a password takes 1 second of CPU time with LUKS, so if you had a lot of LUKS containers, these attempts might slow you down. But most people have only one or two and it's actually not uncommon for them to use the same passphrase.

I actually couldn't locate the source code specifically responsible for this, so the above is only conjecture and I have no idea if this is a feature you could choose to disable somehow.

Found what seems to be the responsible code, see it here on Github.

There's a for loop that starts with tries = 0 and increments tries by one each iteration.

This loop calls get_password() with bool accept_cached set to true if tries == 0 && !arg_verify. So if there are already passwords cached in the first iteration of the loop, it will just return the cached passwords. If those don't work, next iteration with tries == 1 sets accept_cached to false and only then it will ask you to provide another passphrase to try with.

The list of passwords is passed on to attach_luks_or_plain(). This will be the previously cached password(s) in the first iteration, and the single new password in all following ones, so it won't re-try previously tried passwords (unless perhaps if you keep typing in the same one).

As for keeping passwords plaintext in memory, the list of passwords is declared as a _cleanup_strv_free_erase_ char **passwords = NULL; so that at least makes it sounds like cleanup will be taken care of properly at some point.

Keys are always in memory somewhere, that much can't be helped, crypt needs masterkey to work, as long as the container is open, you can always see it with dmsetup table --showkeys.

It seems like you normally have arg_tries = 3 three attempts to enter a working passphrase, but if you have multiple containers and the cached passwords didn't work, it will only give you two tries to enter the passphrase, since the cached password attempt already counts as the first try. I have no encrypted systemd machine to test if this is true or I'm just misreading the code somewhere.

You still have to resize the filesystem using the resized block device. The precise method and possible limitations depend on each filesystem.

Here are two examples to resize the filesystems to the whole available size for EXT4 and XFS. An other filesystem will require an other specific command.

• An EXT4 filesystem can be enlarged online or offline (and can also be shrunk, but only offline).

  resize2fs /dev/mapper/cryptdevice
  

• An XFS filesystem can only be enlarged, and online (can't be shrunk back once done).

  The filesystem must be mounted to be grown. The command requires the mountpoint rather than the block device.

  mount -t xfs /dev/mapper/cryptdevice /mnt
  
  xfs_growfs /mnt
  

You actually missed this step twice from the links:

• Resize LUKS Volume(s)

  in the question:

  # Step 5: Resize encrypted volume (Trying to give it some space)
  > resize2fs -p /dev/CryptVolumeGroup/root 101G
  

  but in the answer:

  Enlarge the rootfs logical volume. No need to un-mount since ext4 and be enlarged while mounted: lvresize -r -L +100G archvg/home

  lvresize -r resizes automatically the underlying filesystem, hence no specific command in the answer. Resizing the filesystem for your specific case not using LVM wasn't present in this answer.

• Increase the size of a LUKS encrypted partition

  As a final step, the file-system needs to be expanded to the new size. With the resize2fs(8) command the file-system is extended to the new size of the LUKS volume.

  $ sudo resize2fs /dev/mapper/sdb1_crypt
  resize2fs 1.42.13 (17-May-2015)
  Filesystem at /dev/mapper/sdb1_crypt is mounted on /media/gerhard/Daten; on-line resizing required
  old_desc_blocks = 2, new_desc_blocks = 4
  The filesystem on /dev/mapper/sdb1_crypt is now 14647925 (4k) blocks long.
  

• Resizing LVM-on-LUKS

  Resizing the encrypted volume

  Now we are going to resize the encrypted volume itself. By taking in account the total size of the logical volume minus some safety space:

  # resize2fs -p /dev/CryptVolumeGroup/Home 208G