I've been looking into the cryptsetup tool and I just wanted to mention some
bugs/undocumented features I came across.
1 detached headers
------------------
For a Luks setup that uses a detached header, a lot of the cryptsetup commands
don't work in an intuitive way. Specifically, the "--header" option is ignored
and cryptsetup throws an error that the specified device is not a Luks device.
The cryptsetup commands work when the path to the actual luks device is
replaced with the path to the header file. This was the case for the following
commands:
luksDump
luksAddKey
luksKillSlot
I didn't check for the other commands. If this is the intended behavior, I
think it should be mentioned in the doucmentation that the header file should
be used in place of the <device> argument in the case of detached LUKS headers.
2 master-key-file with new-key-file
-----------------------------------
For the luksAddKey command, when the "--master-key-file" argument is specified,
the new-key-file positional argument is ignored. Whether or not a file is
provided for the new pass phrase, the user is prompted to enter a pass phrase.
The problem is in the implementation of the function "action_luksAddKey" in
"src/cryptsetup.c". Consider the following lines (916 - 927):
if (opt_master_key_file) {
r = _read_mk(opt_master_key_file, &key, keysize);
if (r < 0)
goto out;
//FIXME: process keyfile arg
r = crypt_keyslot_add_by_volume_key(cd, opt_key_slot,
key, keysize, NULL, 0);
} else if (opt_key_file || opt_new_key_file) {
r = crypt_keyslot_add_by_keyfile_offset(cd, opt_key_slot,
opt_key_file, opt_keyfile_size, opt_keyfile_offset,
opt_new_key_file, opt_new_keyfile_size, opt_new_keyfile_offset);
} else {
When the master key is present, the code doesn't check "opt_new_key_file" and
assumes that the user should be prompted for the pass phrase.
Is this the intended behavior of luksAddKey?
regards,
Safayet Ahmed
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
