cryptsetup status exits prematurely when --header is omitted

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a LUKS volume with a header on a separate device
2. unlock the LUKS volume with the header on a separate device
3. run cryptsetup status /dev/mapper/device_mapper_path

What is the expected output? 
I expected to see something like:
/dev/mapper/zuluCrypt-500-NAAN-test.img-1755010065 is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 256 bits
  device:  /dev/loop0
  loop:    /home/ink/test.img
  offset:  0 sectors
  size:    40000 sectors
  mode:    read/write
  flags:   discards
[root@mtz ink]# 

What do you see instead?
I see this instead:
[root@mtz ink]# cryptsetup status 
/dev/mapper/zuluCrypt-500-NAAN-test.img-1755010065
/dev/mapper/zuluCrypt-500-NAAN-test.img-1755010065 is active and is in use.
[root@mtz ink]# 

Adding --header argument gives the expected and the first provided result but 
its not ideal to give this option all the time since.

What version of the product are you using? On what operating system?
cryptsetup 1.6.3 on linux

Please provide any additional information below.

I am trying to support opening of LUKS volumes from a detached header or from a 
header backup file and presenting a "--header" argument does not work because 
my tools need some of the "missing" information when they startup or when they 
refresh their UI.

"dmsetup info" and "dmsetup table" has most of the information and it would be 
nice if cryptsetup would provide them for me even with this particular use case 
to alleviate the need to go under it to dig up these information myself.

Original issue reported on code.google.com by mhogomch...@gmail.com on 26 Mar 2014 at 3:37

[GoogleCodeExporter]

Yes, you are right that all status information a in DM device table.

But it was intentional limitation here - we need LUKS header to properly 
initialize context to CRYPT_LUKS1. What should happen e.g. when you will later 
query key slots?

So LUKS device without header appears like "unknown" device, basically allowing 
only crypt_deactivate().

But I agree status should print some more info... Not a priority but will think 
how to fix that.

Thanks.

Original comment by gmazyl...@gmail.com on 27 Mar 2014 at 6:52

• Changed state: Accepted

[GoogleCodeExporter]

Added some support for status for "unknown" crypt device
https://code.google.com/p/cryptsetup/source/detail?r=0614ab6b070b3af44bb7aabf4c2
fedc3d1fe1e0c

The type is not available (n/a) but cipher and key size option can be used.

Original comment by gmazyl...@gmail.com on 14 Jun 2014 at 3:46

• Changed state: Fixed

[GoogleCodeExporter]

It now returns values but most of them are missing.This is what i am seeing 
here:

[root@mtz cryptsetup]# /usr/sbin/cryptsetup status 
/dev/mapper/zuluCrypt-500-NAAN-header-image-file.img-3107929503 
/dev/mapper/zuluCrypt-500-NAAN-header-image-file.img-3107929503 is active and 
is in use.
  type:    n/a
  cipher:  (null)-(null)
  keysize: 0 bits
  device:  /dev/loop0
  loop:    /home/ink/zc/header-image-file.img
  offset:  0 sectors
  size:    40000 sectors
  mode:    readonly
[root@mtz cryptsetup]#

Original comment by mhogomch...@gmail.com on 14 Jun 2014 at 5:09

[GoogleCodeExporter]

Are you sure you are using correct libcryptsetup with changes? It seems like 
only cryptsetup binary change is applied here.

# src/cryptsetup status x
/dev/mapper/x is active.
  type:    n/a
  cipher:  aes-xts-plain64
  keysize: 256 bits
  device:  /dev/sdb
  offset:  0 sectors
  size:    417792 sectors
  mode:    read/write

Original comment by gmazyl...@gmail.com on 14 Jun 2014 at 5:18

[GoogleCodeExporter]

yes,the old libcryptsetup would have failed as i reported in my initial bug 
report.

The old libcryptsetup would also not have reported "n/a" as type as my latest 
report indicated.

Have you tried the test on an image file?

Original comment by mhogomch...@gmail.com on 14 Jun 2014 at 6:00

[GoogleCodeExporter]

Nope, check which libcryptsetup you are using - you have probably compiled new 
one but cryptsetup uses system installed version.
(I will increase version in release but not now.)

See - this is with wrapper (so devel library is used)

# src/cryptsetup status x
/dev/mapper/x is active.
  type:    n/a
  cipher:  aes-xts-plain64
  keysize: 256 bits
  device:  /dev/loop1
  loop:    /img.tst
  offset:  0 sectors
  size:    65536 sectors
  mode:    readonly

And this is how it looks like when it uses old library

# src/.libs/cryptsetup status x
/dev/mapper/x is active.
  type:    n/a
  cipher:  (null)-(null)
  keysize: 0 bits
  device:  /dev/loop1
  loop:    /img.tst
  offset:  0 sectors
  size:    65536 sectors
  mode:    readonly

# ldd src/.libs/cryptsetup |grep libcryptsetup
        libcryptsetup.so.4 => /usr/lib/libcryptsetup.so.4 (0xb772d000)

Original comment by gmazyl...@gmail.com on 14 Jun 2014 at 7:50

[GoogleCodeExporter]

I only one libcryptsetup installed and its from the latest git version.

It seems like you are getting the results you are getting because the mapper is 
not in use,put a file system on it and then mount it and you will get the 
output i am getting.Here is an example

[root@mtz cryptsetup]# cryptsetup status /dev/mapper/rrr 
/dev/mapper/rrr is active and is in use.
  type:    n/a
  cipher:  (null)-(null)
  keysize: 0 bits
  device:  /dev/mapper/lvm-p
  offset:  0 sectors
  size:    40960 sectors
  mode:    read/write
[root@mtz cryptsetup]# umount /dev/mapper/rrr
[root@mtz cryptsetup]# cryptsetup status /dev/mapper/rrr 
/dev/mapper/rrr is active.
  type:    n/a
  cipher:  aes-xts-plain64
  keysize: 256 bits
  device:  /dev/mapper/lvm-p
  offset:  0 sectors
  size:    40960 sectors
  mode:    read/write
[root@mtz cryptsetup]#

Original comment by mhogomch...@gmail.com on 14 Jun 2014 at 8:33

[GoogleCodeExporter]

Ah, you are right. This was stupid cleanup mistake before commit.
Try it now.

Thanks.

Original comment by gmazyl...@gmail.com on 14 Jun 2014 at 9:09

[GoogleCodeExporter]

It now works as expected.

crypt_get_type() still return NULL though.Is this expected return value?

It seems contradicting for the binary to return "n/a" while the API returns 
NULL.

Original comment by mhogomch...@gmail.com on 14 Jun 2014 at 9:33

[GoogleCodeExporter]

Yes, type is NULL (as it was previously).

"NULL" or empty string is not much user friendly, so that's why "type not 
available".

I can replace it with something better but have no better idea :)
(But really not NULL, this is more programmer's jargon.)

Original comment by gmazyl...@gmail.com on 14 Jun 2014 at 9:53