[arch-projects] [RFC][PATCH][initscripts] cryptsetup: add keyfile-size= support

[Tom Gundersen]

On Sun, Jul 29, 2012 at 6:34 PM, Matthew Monaco <dgbaley27 at 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