On Sun, Jul 29, 2012 at 6:34 PM, Matthew Monaco <dgbaley27@0x01b.net> wrote:
On 07/28/2012 06:15 PM, Tom Gundersen wrote:
This is useful e.g. if the keyfile is a raw device, where only parts of it should be read. It is typically used whenever the keyfile-offset= option is specified. ---
This patch is compile-tested only, and just meant for gathering feedback. Do you guys agree that this is necessary and sufficient to cover the use-case brought up by Heiko?
Cheers,
Tom
man/crypttab.xml | 11 +++++++++++ src/cryptsetup/cryptsetup.c | 22 +++++++++++++++------- 2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/man/crypttab.xml b/man/crypttab.xml index 2fa8e89..ba3f750 100644 --- a/man/crypttab.xml +++ b/man/crypttab.xml @@ -131,6 +131,17 @@
Sorry to if I restate obvious things but part of the problem is all of the similarly named flags. This patch removes the double-duty for size= corresponding to --key-size and --keyfile-size. We are left with size= just meaning --key-size and no ability to pass the --size option.
Well, not exactly. If keyfile-size is unset, or set at 0, then this patch does not make a difference at all. Moreover, when using PLAIN encryption, keyfile-size is always ignored, and calculated from key-size as before. I'll add a note about this to the manpage. I'll also fix a typo I just noticed in the patch ;-)
I *think* this leaves us with how the cryptsetup frontend handles the two options.
HOWEVER, there are still problems with systemd-cryptsetup. The most obvious thing is that sysd uses crypt_activate_by_volume_key(), but cryptsetup itself only uses this in conjunction with the --master-key-file option. The two might be equivalent for PLAIN with no hashing because the data read from the keyfile is the "master key," but I'm worried that their are some subtleties that won't be supported.
Hm, this seems like a separate issue. Worth looking into though.
In the end I think it would be best to support ALL options from cryptsetup that are used for "cryptsetup luksOpen" and/or "cryptsetup create" regardless of whether we think they're only useful for ad hoc mappings.
I think the best approach would be to submit one patch per feature (and make sure to find a use-case for it). -t