[systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device

[Dimitri John Ledkov]

On 24 April 2015 at 10:06, Lennart Poettering <lennart at poettering.net> wrote:
> On Thu, 23.04.15 21:04, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:
>
>> On 23 April 2015 at 13:08, Lennart Poettering <lennart at poettering.net> wrote:
>> > On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidjaar at gmail.com) wrote:
>> >
>> >> > > > What does this actually do? Is the specified key file read from the
>> >> > > > specified device?
>> >> > >
>> >> > > It reads keyfile from filesystem on device identifed by keyfile_device.
>> >> > >
>> >> > > >                  The order of keyfile:device sounds weird, no?
>> >> > > > Shouldn't it be the other way round?
>> >> > > >
>> >> > >
>> >> > > keyfile is mandatory, keyfile_device is optional and can be omitted. I
>> >> > > believe dracut looked at all existing devices then. This order makes
>> >> > > it easier to omit optional parameter(s).
>> >> >
>> >> > Well, whether it is [device:]file or file[:device] is hardly any
>> >> > difference for the parser...
>> >>
>> >> Does it really matter?
>> >
>> > Well, we might as well implement this in the most obvious way if it is
>> > not a completely standard feature yet. To me it appears that only one
>> > initrd supported it, and it lost it a while back without too much
>> > complaining...
>> >
>> > But anyway, I don't mind too much. The
>> >
>>
>> debian's initramfs-tools, but not ubuntu's, support keyfile on
>> usb-disk for unlocking luks volumes.
>>
>> the exact name of the option and semantics to specify it to
>> initramfs-tools is different from dracut's (but that's typical) but
>> said equivalent feature does exist in the major other initramfs
>> implementation.
>
> What's the syntax of Debian's initrd for this?
>
> I mean, if their syntax makes more sense, we might standardise on theirs...
>

So in debian this is done via keyscript argument in /etc/crypttab, and
there is passdev keyscript provided by the package that is typically
used.
initramfs-tools hooks copy all of those into initramfs.

The passdev is a C binary that takes a single argument -
<device>:<filepath>[:<timeout>]
The binary waits for the device to appear (infinity or up to
optionally specified time-out parameter), mounts it read-only, and
read the filepath to attempt luks unlock for the device specified in
the crypttab.

See docs and sources at:

https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debian/README.Debian/#L139

https://sources.debian.net/src/cryptsetup/2:1.6.6-5/debian/passdev.c/

I am indifferent about configuration done via keyscript= parameter in
crypttab, the quality of the passdev implementation. But the
<device>:<filepath>[:<timeout>] argument format is imho a simple &
sensible one for this.

There are a bunch of other keyscript= binaries provided for remote
unlocking over ssh, smartcards, yubikeys and so on, because debian
supports arbitrary things there. A lot of the times people write their
own keyscript by hand for their usecases. =) as usual debian prefers
arbitrary code execution instead of something rigidly declarative ;-)

-- 
Regards,

Dimitri.
Pura Vida!

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.