Bug 1778136
| Summary: | [RFE] Implement dmsetup table --tree to show device tables in similar order as stacked devices | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | ricky.tigg |
| Component: | lvm2 | Assignee: | LVM Team <lvm-team> |
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | rawhide | CC: | agk, anprice, bmarzins, bmr, cfeist, heinzm, jbrassow, jonathan, kzak, lvm-team, mcsontos, msnitzer, prajnoha, prockai, zkabelac |
| Target Milestone: | --- | Keywords: | FutureFeature, RFE |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | Bug | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
dmsetup tool is relatively 'straight/raw' interface between kernel and user space - so you get these things in the 'order' provided by kernel. So as instant workaround what you can do here is to add shell script - to 'obtain' list of device in some 'meaningful' order - whether it would be a name order, UUID order, disk dependency order and then reshuffle individual table lines to match the logic. ATM there is no support for 'reporting & select' for table output - only for 'dmsetup info' which is form of 'interpreting' command. As for dmsetup table output extensio - it seems like the way forward could be to extend 'table' command with '--tree' option we use for 'ls' command. Outputs from 'dmsetup table --showkeys' and 'dmsetup table --showkeys --tree' are identical. I noticed that my LVM system partition using LUKS, created at installation –which relied on Anaconda– has its password encrypted –here replaced by "[...]"–. That password listed then by 'dmsetup' is not by 'cat /etc/shadow'. It had then to be added by default into kernel! Was it, as I suppose it, hashed? If yes, it would have been salted since there is no match from list of hash results within GtkHash while all available hash are selected for listing. Since cryptsetup v.2.1.0 and up, LUKS2 is default format from an upstream perspective. LKUKS volumes created with such Cryptsetup version onto an attached SCSI removable disk, by using option '--disable-keyring', are not listed by 'dmsetup'. Is that to be the expected behaviour? I don't understand what's the claim here exactly, so I'll try to explain why you could have seen different output from dmsetup table command: There are 2 methods how to get device volume keys in kernel 1) classical method (used with LUKS1 format, plain crypt devices, keys for dm-integrity target) where cryptsetup uploads keys directly in dm crypt kernel structure. Such keys get exposed with dmsetup table --showkeys output only and are printed in hexbyte representation. There's no hash or key encryption, it's the device volume key in plain text. Never *ever* post output from dmsetup table with --showkeys parameter anywhere in public. You were right to replace those with [...]. 2) Keys loaded in kernel via kernel keyring service. In this case dm-crypt structure does not hold the key itselfs but only reference kernel keyring identification (key description). dmsetup table output with keys described by string ":96:logon:cryptsetup:262a80d6-76a0-4937-99e6-73516aae5ddc-d0" are harmless. It's just string that can be decoded as followfs: :<keys_size>:<key_type>:<key_description>. The key description used with cryptsetup is always prefixed by 'cryptsetup' followed by device UUID and internal digest id (hence the -d0 suffix). LUKS2 format use kernel keyring service for uploading keys by default since v2.0.0, but we did not change the behavior for LUKS1 device and crypt plain devices. Could it be that /dev/sda6 actually contains LUKS1 device? "I don't understand what's the claim"; That's just obvious from report you wrote, since as expected from such statement it was not related to Actual and Expected results. Thought you managed by your own to produce a relevant title as "Implement 'dmsetup table --tree' to show device tables in similar order as stacked devices" accurately close to Actual and Expected results. Strange how things are with humans. "/dev/sda6 actually contains LUKS1 device"; That's indeed LUKS1 'dmsetup info -c' reports. |
Enhancement request: output resulting from 'dmsetup table --showkeys' mixes, in listing, elements related to different volumes. Version-Release number of component: device-mapper.x86_64 1.02.165-1.fc31 @updates How reproducible: # dmsetup table --showkeys fedora-sivutus: 0 16326656 linear 253:0 345262080 luks-262a80d6-76a0-4937-99e6-73516aae5ddc_dif: 0 195768 integrity 8:18 32768 32 J 5 journal_sectors:1848 interleave_sectors:32768 buffer_sectors:128 journal_watermark:50 commit_time:10000 fedora-koti: 0 18874368 linear 253:0 326387712 luks-262a80d6-76a0-4937-99e6-73516aae5ddc: 0 195768 crypt capi:authenc(hmac(sha256),xts(aes))-plain64 :96:logon:cryptsetup:262a80d6-76a0-4937-99e6-73516aae5ddc-d0 0 253:4 0 1 integrity:32:aead fedora-juuri: 0 326385664 linear 253:0 2048 luks-acf8855f-302b-4ea5-90f6-12a256deb1fa: 0 361598976 crypt aes-xts-plain64 [...] 0 8:6 4096 1 allow_discards Actual results: output mixes rows related to different volumes, here for instance sda6 and sdb2 as referenced in lsblk. Thus, this incoherent listing is prone to make mistakes of interpretations. Expected results: # dmsetup table --showkeys ' luks-acf8855f-302b-4ea5-90f6-12a256deb1fa: 0 361598976 crypt aes-xts-plain64 [...] 0 8:6 4096 1 allow_discards fedora-juuri: 0 326385664 linear 253:0 2048 fedora-koti: 0 18874368 linear 253:0 326387712 fedora-sivutus: 0 16326656 linear 253:0 345262080 luks-262a80d6-76a0-4937-99e6-73516aae5ddc_dif: 0 195768 integrity 8:18 32768 32 J 5 journal_sectors:1848 interleave_sectors:32768 buffer_sectors:128 journal_watermark:50 commit_time:10000 luks-262a80d6-76a0-4937-99e6-73516aae5ddc: 0 195768 crypt capi:authenc(hmac(sha256),xts(aes))-plain64 :96:logon:cryptsetup:262a80d6-76a0-4937-99e6-73516aae5ddc-d0 0 253:4 0 1 integrity:32:aead ' Additional info: $ lsblk -o name,fstype,mountpoint,type,tran,subsystems NAME FSTYPE MOUNTPOINT TYPE TRAN SUBSYSTEMS sda disk sata block:scsi:pci ├─sda5 ext4 /boot part block:scsi:pci └─sda6 crypto_LUKS part block:scsi:pci └─luks-acf8855f-302b-4ea5-90f6-12a256deb1fa LVM2_member crypt block ├─fedora-juuri ext4 / lvm block ├─fedora-sivutus swap [SWAP] lvm block └─fedora-koti ext4 /home lvm block sdb disk usb block:scsi:usb:pci └─sdb2 crypto_LUKS part block:scsi:usb:pci └─luks-262a80d6-76a0-4937-99e6-73516aae5ddc_dif crypt block └─luks-262a80d6-76a0-4937-99e6-73516aae5ddc vfat /run/media/yk/salataltio1 crypt block