From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from v6.tansi.org (ns.km31936-01.keymachine.de [87.118.116.4]) by mail.server123.net (Postfix) with ESMTP for ; Sat, 24 Jan 2015 01:16:46 +0100 (CET) Received: from gatewagner.dyndns.org (77-57-54-224.dclient.hispeed.ch [77.57.54.224]) by v6.tansi.org (Postfix) with ESMTPA id DB9F220DC1F9 for ; Sat, 24 Jan 2015 01:10:11 +0100 (CET) Date: Sat, 24 Jan 2015 01:10:11 +0100 From: Arno Wagner Message-ID: <20150124001011.GA6072@tansi.org> References: <1e29b33d93a2ef0bff68a56208684dcc.squirrel@ssl.verfeiert.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1e29b33d93a2ef0bff68a56208684dcc.squirrel@ssl.verfeiert.org> Subject: Re: [dm-crypt] Bugs/Undoucmented features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: dm-crypt@saout.de On Fri, Jan 23, 2015 at 23:23:16 CET, Sven Eschenberg wrote: > On Fri, January 23, 2015 22:33, Ahmed, Safayet (GE Global Research) wrote: > > 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 argument in the case of detached LUKS > > headers. > > Operations on the HEADER naturally require the header and not the actual > payload. It would be redundant to pass the payload (device) and naturally > the header is the only (direct) parameter. Should this be mentioned more > clearly in the docs/manpage? Possibly yes. While this is obvious behavior if you have the LUKS data model in mind, I think it is a valid criticism of the documentation. I will make this more obvious in the man-page and maybe add an FAQ-item. May take a week or two though, I currently have a lot of work. > > > > > > 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. > > I think I reported this quite a while back and it was supposedly fixed > some while ago (2010 IIRC). This code seems to still be in 1.6.5, but starting at line 955. > > > > 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? I think this is actually a defect. It is a minor one, as using the master-key is an emergency-only operation and hence likely done manyally anyways. But if I am right and it is a defect, it should probably get an item on the issues-list. Gr"usse, Arno > > regards, > > > > Safayet Ahmed > > _______________________________________________ > > dm-crypt mailing list > > dm-crypt@saout.de > > http://www.saout.de/mailman/listinfo/dm-crypt > > > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@saout.de > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@wagner.name GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- A good decision is based on knowledge and not on numbers. -- Plato If it's in the news, don't worry about it. The very definition of "news" is "something that hardly ever happens." -- Bruce Schneier