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. 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. 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.