[dm-crypt] Bugs/Undoucmented features

Ahmed, Safayet (GE Global Research) Safayet.Ahmed at ge.com
Fri Jan 23 22:33:26 CET 2015

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 


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?


Safayet Ahmed

More information about the dm-crypt mailing list