Also by using --test-passphrase option this patch allows
cryptsetup to check if specific token (--token-id) is
able to unlock specific keyslot (--key-slot/-S).
It uses recently added crypt_activate_by_keyslot_context
API.
Fixes: #784.
When adding new keyslot we check if provided existing
passphrase is correct first.
Since user may now select specific existing keyslot
(to extract volume key) it's no use to check any
matching keyslot. Test passphrase only for user
specified keyslot.
Unlike LUKS, plain mode uses no metadata where configured.
As we need to upgrade algorithms form time to time because of security
reasons, warn user to specify these options explicitly.
Related #758.
Fix a path with default kernel key type assumed.
It did not check correctly for return value from
asprintf and would leak the allocated memory
instead.
We can not link internal VK kernel key in custom user
keyring. There are two reasons for it:
The internal VK kernel key description can not be
acquired via API and it may change over time
(LUKS2 reencryption).
With recent SED OPAL support volume key becomes a 'blob'
containing up to two keys (dm-crypt key for SWE and key
for unlocking SED OPAL locking range). The internal
kernel key contains only dm-crypt (if required) but
custom user keyring needs to be provided with whole
volume key (blob).
Added user specified key description for the linked key
in custom user keyring. The linked key can be reached by
the specified description after successful activation (resume).
If old util-linux is used, blkid scan can fail because disk
is already locked for OPAL.
Do the same for other internal blkid issue.
Also add some debug messages to be clear what's going on.
Add --volume-key-keyring option, which takes a name of a key in keyring,
which will be used as a VK during device activation. The key can be
specified in keyctl-compatible syntax "%<key_type>:<key_name>".
When using the --link-vk-to-keyring option, allow specifying the keyring
using the same syntax as keyctl (see "man keyctl"). E.g. "@u" for user
keyring and "%:testring" for a user-created keyring.
Add a new API crypt_set_keyring_to_link nad CLI option
--link-vk-to-keyring. This allows the user to specify ID of the keyring
where the VK should be linked.
Wipe and disable the segment. Also support the factory reset ioctl for
a complete wipe of the entire drive with a specific argument.
Signed-off-by: Luca Boccassi <bluca@debian.org>
Activation with header only fails too late (in device-mapper
call) while it is clear from the beginning that it cannot succeed.
Just add an early and better worded error.
Ignore this situation for block device (we have to call ioctl to get size).
The most common case is a file container here anyway.
For block devices it fails during activation later.
In practice luksAddKey action does two operations. It unlocks existing
device volume key and stores unlocked volume key in a new keyslot.
Previously the options were limited to key files and passphrases.
With this patch user may combine freely following options:
To unlock keyslot with volume key user may:
- provide existing passphrase via interactive prompt (default method)
- use --key-file option to provide file with a valid passphrase to existing keyslot
- provide volume key directly via --volume-key-file
- unlock keyslot via all available LUKS2 tokens by --token-only
- unlock keyslot via specific token with --token-id
- unlock keyslot via specific token type by --token-type
To provide the passphrase for a new keyslot user may:
- provide existing passphrase via interactive prompt (default method)
- use --new-keyfile parameter or positional parameter to read the
passphrase from file.
- use --new-token-id to select specific LUKS2 token to get passphrase
for new keyslot. New keyslot is assigned to selected token id if
operation is succesfull.
Fixes: #725.
Ths will allow automatic scan of known formats.
Errors are printed only if something is wrong with already detected metadata.
This change means that it is responsibility of the caller to print an error
message if needed.
Also fix some places without a message.
Fixes: #642
It can be used to enforce offline reencryption
in batch mode when data_device is regular file
and therefore cryptsetup cannot detect properly
active device dm name.
Also it may be useful when active device
auto-detection fails for some reason and user
has no other choice but inspect device holders
manually.
