LUKS2 resizing
Hi,
I was testing how well KDE Partition Manager works on LUKS2 partitions. Apparently, it fails to resize them. It seems that now cryptsetup resize asks for passphrase before resizing the container.
Unfortunately, I wasn't able to find any documentation on this. So, the passphrase is now required to resize the container? When I tried entering wrong passphrase, cryptsetup silently returns exit code 2, not 0. I guess cryptsetup refused to resize. Am I right?
Andrius
Signature · 4 lines
I encourage the use of end to end email encryption GPG key: https://stikonas.eu/andrius.asc Fingerprint: 1EE5 A320 5904 BAA2 B88C 0A9D 24FD 3194 0095 C0E1
Quoted 3 lines · Andrius Štikonas
I was testing how well KDE Partition Manager works on LUKS2 partitions. Apparently, it fails to resize them. It seems that now cryptsetup resize asks for passphrase before resizing the container.
Yes, cryptsetup utility asks for passphrase if it detects volume key was previously passed to dm-crypt via kernel keyring service. VK is passed to kernel keyring by default for LUKS2 devices.
Quoted 4 lines
Unfortunately, I wasn't able to find any documentation on this. So, the passphrase is now required to resize the container? When I tried entering wrong passphrase, cryptsetup silently returns exit code 2, not 0. I guess cryptsetup refused to resize. Am I right?
Unfortunately we forgot to regenerate doxygen API documentation together with 2.0.0 final release. But we fixed the mistake recently.
See note at bottom of crypt_resize() description: https://gitlab.com/cryptsetup/cryptsetup/wikis/API/group__crypt-actions.html#ga168bcd5097cdf64774540fdeaacefbc0
On libcryptsetup API level, you can either query active device (crypt_get_active_device()) and check for CRYPT_ACTIVATE_KEYRING_KEY flag. The flag raised means you should load volume key to keyring before crypt_resize(). Or, you can detect return value from crypt_resize. The -EPERM hints you basically the same.
Thank you for the report. I'll check the silent failure with cryptsetup utility. Yes, in general exit status != 0 says the operation was not performed.
Regards
Ondrej
A message that is not in the archive (sent off-list or not yet received): 2297498.LbHdjMTUMS@laptop
A message that is not in the archive (sent off-list or not yet received): [email protected]
Hi,
I don't think --ask-always option would be necessary... I think cryptsetup status is more than enough. I have to do some screen scrubbing in other places too, e.g. new file system (and version version) detection code now screen scrubs "udevadm info --query property" to detect whether e.g. it is LUKS1 or LUKS2 or even FAT12.
Actually, do I even need cryptsetup status KDE Partitition Manager only allows resizing unlocked LUKS volumes (so that internal file system can also be resized). So if I understand correctly it will never ask for passphrase in LUKS1 case but it will always ask in LUKS2 case.
Andrius
2017 m. gruodžio 14 d., ketvirtadienis 10:23:21 GMT rašėte:
Quoted 30 lines · Andrius Štikonas
Quoted 6 lines
Exit code status should be fine for me. I'll just check for it to be 0. I can't really use libcryptsetup anyway, I need to use cryptsetup executable as
KDE Partition Manager is a GUI app and linking to libcryptsetup would require the whole app to be running as root which is a security issue for GUI apps.I see.
Well, you may either detect volume key was passed via kernel keyring to dm-crypt by following command: cryptsetup status <name>
It prints usual status information together with line:
"key location: keyring". If you see such line you know cryptsetup resize will ask for passphrase. But yes, it's screen scrubbing, not comfortable.Or, we may implement option --ask-always (or similar) and cryptsetup resize will ask always for the passphrase to verify (and also load) volume key during resize operation.
Would it help?
Also do you mind if I repost this e-mail back to mail list so that others see my answer?
O.
Signature · 4 lines
I encourage the use of end to end email encryption GPG key: https://stikonas.eu/andrius.asc Fingerprint: 1EE5 A320 5904 BAA2 B88C 0A9D 24FD 3194 0095 C0E1
Quoted 2 lines · Andrius Štikonas
So if I understand correctly it will never ask for passphrase in LUKS1 case but it will always ask in LUKS2 case.
Not always for every LUKS2 device. It will always ask for a passphrase if the volume key is passed via kernel keyring (hence the cryptsetup status cmd for detection).
LUKS1 devices doesn't use kernel keyring for volume key (backward compatibility)
LUKS2 devices use kernel keyring for volume key by default, but user may have overridden the default by --disable-keyring option during cryptsetup open command.
Regards
Ondrej
Quoted 8 lines · Ondrej Kozina
Quoted 2 lines · Andrius Štikonas
So if I understand correctly it will never ask for passphrase in LUKS1 case but it will always ask in LUKS2 case.
Not always for every LUKS2 device. It will always ask for a passphrase if the volume key is passed via kernel keyring (hence the cryptsetup status cmd for detection).
Quoted 7 lines
LUKS1 devices doesn't use kernel keyring for volume key (backward compatibility)
LUKS2 devices use kernel keyring for volume key by default, but user may have overridden the default by --disable-keyring option during cryptsetup open command.
And don't forget not every kernel has dm-crypt kernel keyring support available. We detect dm-crypt version runtime so you may encounter LUKS2 devices with hexbyte key in dm table directly, especially in enterprise or more conservative distributions. I'd recommend to stick with cryptsetup status cmd for detection though.
O.