Bug 1733390

(In reply to Corey Marthaler from comment #0)
> # No valid active name (but a valid device in its place) with a valid header
> (NO PROPER WARNING)
> [root@hayes-02 ~]# cryptsetup reencrypt --decrypt --active-name
> /dev/cache_sanity/fs_snap2 --header /tmp/cache_luks_header.1234567890
> [root@hayes-02 ~]# cryptsetup reencrypt --decrypt --active-name
> /dev/cache_sanity/fs_snap2 --header /tmp/cache_luks_header.1234567890
> [root@hayes-02 ~]# echo $?
> 4 

What device is /dev/cache_sanity/fs_snap2 exactly? I can't reproduce your failure exactly:

With Beta build:

a) when I pass dm linear mapping of other existing device (not LUKS2) I get:

cryptsetup reencrypt --decrypt --active-name /dev/mapper/some_linear --header /tmp/my_hdr
This operation is not supported for this device type.

b) If I pass activate LUKS2 device, but I use full path instead of dm name (/dev/mapper/my_crypt instead of just "my_crypt"), I get:

cryptsetup reencrypt --decrypt --active-name /dev/mapper/my_crypt --header /tmp/my_hdr
Enter passphrase for /dev/sdc: 
Name "/dev/mapper/my_crypt-hotzone" invalid. It contains "/".
Failed to activate hotzone device /dev/mapper/my_crypt-hotzone.
Failed to initalize reencryption device stack.

This is clearly bug (perhaps yet another one), but I would like to reproduce your scenario as well.

c) If I pass other block device (sdb1 partition), I get:

cryptsetup reencrypt --decrypt --active-name /dev/sdb1 --header /tmp/my_hdr
Device sdb1 not found

This may require hitting bug 1733391 first. 

I tried to reproduce this with just valid encrypted origin/snap volumes but wasn't able to (ie i saw valid warnings/errors). I then attempted right after bug 1733391, and saw this issue again. I'll look into this more and try and repo w/o bug 1733391 and see if it's possible, otherwise we can close this a dup of 1733391.

I reproduced it w/o bug 1733391. It's just an active open snapshot of luks origin.

[root@hayes-01 ~]# lvcreate -n origin -L 4G test
  Logical volume "origin" created.
[root@hayes-01 ~]# echo foobarglarch | cryptsetup reencrypt --encrypt --init-only --type luks2 /dev/test/origin --header /tmp/cache_luks_header.1234567890
[root@hayes-01 ~]# echo foobarglarch | cryptsetup luksOpen /dev/test/origin luks_corigin --header /tmp/cache_luks_header.1234567890

[root@hayes-01 ~]# lvcreate  -s /dev/test/origin -c 64 -n fs_snap1 -L 4100.00m
  Logical volume "fs_snap1" created.
[root@hayes-01 ~]# cp /tmp/cache_luks_header.1234567890 /tmp/cache_luks_header.for_snapshot

[root@hayes-01 ~]# echo foobarglarch | cryptsetup luksOpen /dev/test/fs_snap1 luks_fs_snap1 --header /tmp/cache_luks_header.for_snapshot

# fails
[root@hayes-01 ~]# cryptsetup reencrypt --decrypt --active-name /dev/test/fs_snap1 --header /tmp/cache_luks_header.for_snapshot
[root@hayes-01 ~]# echo $?
4

# passes
[root@hayes-01 ~]# cryptsetup reencrypt --decrypt --active-name luks_fs_snap1 --header /tmp/cache_luks_header.for_snapshot
Enter passphrase for /dev/mapper/test-fs_snap1:

I can confirm there are two bugs:

The one Corey described in comment #3

- and -

> b) If I pass active LUKS2 device, but I use full path instead of dm name (/dev/mapper/my_crypt instead of just "my_crypt"), I get:
>
> cryptsetup reencrypt --decrypt --active-name /dev/mapper/my_crypt --header /tmp/my_hdr
> Enter passphrase for /dev/sdc: 
> Name "/dev/mapper/my_crypt-hotzone" invalid. It contains "/".
> Failed to activate hotzone device /dev/mapper/my_crypt-hotzone.
> Failed to initalize reencryption device stack.

(In reply to Ondrej Kozina from comment #4)
> I can confirm there are two bugs:
> 
> The one Corey described in comment #3

Fixed upstream in https://gitlab.com/cryptsetup/cryptsetup/commit/7380731bf79494d56de672cb9bec337b39287904

Expected error message is "Device /dev/test/fs_snap1 is not a valid LUKS device."


> 
> - and -
> 
> > b) If I pass active LUKS2 device, but I use full path instead of dm name (/dev/mapper/my_crypt instead of just "my_crypt"), I get:
> >
> > cryptsetup reencrypt --decrypt --active-name /dev/mapper/my_crypt --header /tmp/my_hdr
> > Enter passphrase for /dev/sdc: 
> > Name "/dev/mapper/my_crypt-hotzone" invalid. It contains "/".
> > Failed to activate hotzone device /dev/mapper/my_crypt-hotzone.
> > Failed to initalize reencryption device stack.

Fixed upstream in https://gitlab.com/cryptsetup/cryptsetup/commit/97ea39404a8578dd89c7d9134050de6014009045

Reencryption now accepts full device path passed in --active-name parameter. It must be path for LUKS mapped device.

Both issues described in this bug have been verified in the latest rpms.

cryptsetup-2.2.0-1.el8    BUILT: Fri Aug 16 01:22:41 CDT 2019
cryptsetup-libs-2.2.0-1.el8    BUILT: Fri Aug 16 01:22:41 CDT 2019
cryptsetup-reencrypt-2.2.0-1.el8    BUILT: Fri Aug 16 01:22:41 CDT 2019


# issue 1:
[root@hayes-01 ~]# lvcreate -n origin -L 4G test
  Logical volume "origin" created.
[root@hayes-01 ~]# echo foobarglarch | cryptsetup reencrypt --encrypt --init-only --type luks2 /dev/test/origin --header /tmp/cache_luks_header.1234567890
[root@hayes-01 ~]# echo foobarglarch | cryptsetup luksOpen /dev/test/origin luks_corigin --header /tmp/cache_luks_header.1234567890
[root@hayes-01 ~]# lvcreate  -s /dev/test/origin -c 64 -n fs_snap1 -L 4100.00m
  Logical volume "fs_snap1" created.
[root@hayes-01 ~]# cp /tmp/cache_luks_header.1234567890 /tmp/cache_luks_header.for_snapshot
[root@hayes-01 ~]# echo foobarglarch | cryptsetup luksOpen /dev/test/fs_snap1 luks_fs_snap1 --header /tmp/cache_luks_header.for_snapshot

# fails (with a legit error message now)
[root@hayes-01 ~]# echo foobarglarch | cryptsetup reencrypt --decrypt --active-name /dev/test/fs_snap1 --header /tmp/cache_luks_header.for_snapshot
Device /dev/test/fs_snap1 is not a valid LUKS device.
[root@hayes-01 ~]# echo $?
1

# continues to pass
[root@hayes-01 ~]#  echo foobarglarch | cryptsetup reencrypt --decrypt --active-name luks_fs_snap1 --header /tmp/cache_luks_header.for_snapshot
Finished, time 01:55.344, 4096 MiB written, speed  35.5 MiB/s   




# issue 2:
# passed in active LUKS2 device with full path instead of dm name
[root@hayes-01 ~]# lvcreate -n origin -L 4G test
  Logical volume "origin" created.
[root@hayes-01 ~]# echo foobarglarch | cryptsetup reencrypt --encrypt --init-only --type luks2 /dev/test/origin --header /tmp/cache_luks_header.0987654321
[root@hayes-01 ~]# echo foobarglarch | cryptsetup luksOpen /dev/test/origin luks_corigin --header /tmp/cache_luks_header.0987654321
[root@hayes-01 ~]# echo foobarglarch | cryptsetup reencrypt --decrypt --active-name /dev/mapper/luks_corigin --header /tmp/cache_luks_header.0987654321
Finished, time 01:22.156, 4096 MiB written, speed  49.9 MiB/s

The bug was introduced and fixed during 8.1 devel phase, no docs text needed.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3569