Bug 1733345 - [RFE] Provide a general listing of all currently open crypt volumes.
Summary: [RFE] Provide a general listing of all currently open crypt volumes.
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: cryptsetup
Version: 8.1
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: rc
: 8.0
Assignee: Ondrej Kozina
QA Contact: Storage QE
URL:
Whiteboard:
Depends On: 1551155
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-07-25 19:12 UTC by Corey Marthaler
Modified: 2020-02-06 19:58 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of: 1551155
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)

Comment 1 Corey Marthaler 2019-07-25 19:19:32 UTC
I could use lsblk but that's still a lot of output to grep through. I could also just do "for i in $(dmsetup ls); do cryptsetup status $i; done" and find out that way. I'm just saying it would be *so* much easier to just do "cryptsetup list" or "cryptsetup status --all" or something when there are a lot of devices on a system. 
 

[root@hayes-02 ~]# lsblk
NAME                             MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                8:0    0   1.8T  0 disk  
├─sda1                             8:1    0     1G  0 part  /boot
├─sda2                             8:2    0     4G  0 part  [SWAP]
└─sda3                             8:3    0   1.8T  0 part  /
sdb                                8:16   0   1.8T  0 disk  
└─sdb1                             8:17   0   1.8T  0 part  
sdc                                8:32   0   1.8T  0 disk  
└─sdc1                             8:33   0   1.8T  0 part  
sdd                                8:48   0   1.8T  0 disk  
└─sdd1                             8:49   0   1.8T  0 part  
sde                                8:64   0   1.8T  0 disk  
└─sde1                             8:65   0   1.8T  0 part  
sdf                                8:80   0   1.8T  0 disk  
└─sdf1                             8:81   0   1.8T  0 part  
sdg                                8:96   0   1.8T  0 disk  
└─sdg1                             8:97   0   1.8T  0 part  
sdh                                8:112  0   1.8T  0 disk  
└─sdh1                             8:113  0   1.8T  0 part  
sdi                                8:128  0   1.8T  0 disk  
└─sdi1                             8:129  0   1.8T  0 part  
sdj                                8:144  0   1.8T  0 disk  
└─sdj1                             8:145  0   1.8T  0 part  
sdk                                8:160  0   1.8T  0 disk  
└─sdk1                             8:161  0   1.8T  0 part  
sdl                                8:176  0 446.6G  0 disk  
└─sdl1                             8:177  0 446.6G  0 part  
sdm                                8:192  0 446.6G  0 disk  
└─sdm1                             8:193  0 446.6G  0 part  
  └─cache_sanity-corigin_corig   253:3    0     4G  0 lvm   
    └─cache_sanity-corigin-real  253:5    0     4G  0 lvm   
      ├─cache_sanity-corigin     253:0    0     4G  0 lvm   
      │ └─luks_corigin           253:4    0     4G  0 crypt 
      └─cache_sanity-fs_snap1    253:7    0     4G  0 lvm   
        └─luks_fs_snap1          253:8    0     4G  0 crypt 
sdn                                8:208  0 446.6G  0 disk  
└─sdn1                             8:209  0 446.6G  0 part  
  ├─cache_sanity-fs_A_pool_cdata 253:1    0     2G  0 lvm   
  │ └─cache_sanity-corigin-real  253:5    0     4G  0 lvm   
  │   ├─cache_sanity-corigin     253:0    0     4G  0 lvm   
  │   │ └─luks_corigin           253:4    0     4G  0 crypt 
  │   └─cache_sanity-fs_snap1    253:7    0     4G  0 lvm   
  │     └─luks_fs_snap1          253:8    0     4G  0 crypt 
  └─cache_sanity-fs_A_pool_cmeta 253:2    0    12M  0 lvm   
    └─cache_sanity-corigin-real  253:5    0     4G  0 lvm   
      ├─cache_sanity-corigin     253:0    0     4G  0 lvm   
      │ └─luks_corigin           253:4    0     4G  0 crypt 
      └─cache_sanity-fs_snap1    253:7    0     4G  0 lvm   
        └─luks_fs_snap1          253:8    0     4G  0 crypt 
sdo                                8:224  0 446.6G  0 disk  
└─sdo1                             8:225  0 446.6G  0 part  
  └─cache_sanity-fs_snap1-cow    253:6    0     4G  0 lvm   
    └─cache_sanity-fs_snap1      253:7    0     4G  0 lvm   
      └─luks_fs_snap1            253:8    0     4G  0 crypt 
sdp                                8:240  0 446.6G  0 disk  
└─sdp1                             8:241  0 446.6G  0 part  
sr0                               11:0    1  1024M  0 rom

Comment 2 Milan Broz 2019-07-26 06:06:01 UTC
Well, while it is easy for user, running cryptsetup mean *huge* overload comparing to lsblk.
Cryptsetup initializes crypto backend, libdevmapper, a lot of other libraries (we are not locking memory in reporting commands, so this part is simpler).

While lsblk was designed to just read /sys (it can do blkid optionally), it was inteded to be usable even if some devices are suspended.
Also it already provides several different format outputs (including JSON and CSV) so it is more script friendly

So, I would definitely prefer to use lsblk, just add some filtering, if it is mising.

What is the expected output - list all top (use visible) devices of any crypt type?

Comment 3 Corey Marthaler 2019-07-26 22:08:09 UTC
The expected output would be a the active names of opened luks devices.

cryptsetup luksOpen /dev/sdk1 cPV1
cryptsetup luksOpen /dev/sdi1 cPV2
cryptsetup luksOpen /dev/sdn1 cPV3
cryptsetup luksOpen /dev/sdo1 cPV4
cryptsetup luksOpen /dev/sdg1 cPV5
cryptsetup luksOpen /dev/sdl1 cPV6
cryptsetup luksOpen /dev/sdp1 cPV7
cryptsetup luksOpen /dev/sdh1 cPV8
cryptsetup luksOpen /dev/sdm1 cPV9
cryptsetup luksOpen /dev/sdf1 cPV10
cryptsetup luksOpen /dev/sdj1 cPV11
cryptsetup luksOpen /dev/sdd1 cPV12


[root@hayes-03 ~]# lsblk | grep crypt
  ââcPV12 253:11   0 446.6G  0 crypt 
  ââcPV10 253:9    0   1.8T  0 crypt 
  ââcPV5  253:4    0   1.8T  0 crypt 
  ââcPV8  253:7    0   1.8T  0 crypt 
  ââcPV2  253:1    0   1.8T  0 crypt 
  ââcPV11 253:10   0   1.8T  0 crypt 
  ââcPV1  253:0    0   1.8T  0 crypt 
  ââcPV6  253:5    0   1.8T  0 crypt 
  ââcPV9  253:8    0   1.8T  0 crypt 
  ââcPV3  253:2    0   1.8T  0 crypt 
  ââcPV4  253:3    0   1.8T  0 crypt 
  ââcPV7  253:6    0   1.8T  0 crypt 

[root@hayes-03 ~]# dmsetup ls
cPV5    (253:4)
cPV4    (253:3)
cPV3    (253:2)
cPV2    (253:1)
cPV1    (253:0)
cPV12   (253:11)
cPV11   (253:10)
cPV10   (253:9)
cPV9    (253:8)
cPV8    (253:7)
cPV7    (253:6)
cPV6    (253:5)

[root@hayes-03 ~]# cryptsetup status cPV12
/dev/mapper/cPV12 is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 256 bits
  key location: dm-crypt
  device:  /dev/sdd1
  sector size:  512
  offset:  4096 sectors
  size:    936636336 sectors
  mode:    read/write

# Would at least show this:
[root@hayes-03 ~]# cryptsetup list (or ls, or whatever)
cPV5
cPV4
cPV3
cPV2
cPV1
cPV12
cPV11
cPV10
cPV9 
cPV8 
cPV7 
cPV6 

# This would be better
[root@hayes-03 ~]# cryptsetup list (or ls, or whatever)
cPV5    /dev/sdg1
cPV4    /dev/sdo1
cPV3    /dev/sdn1
cPV2    /dev/sdi1
cPV1    /dev/sdk1
cPV12   /dev/sdd1
cPV11   /dev/sdj1
cPV10   /dev/sdf1
cPV9    /dev/sdm1
cPV8    /dev/sdh1
cPV7    /dev/sdp1
cPV6    /dev/sdl1


Note You need to log in before you can comment on or make changes to this bug.