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

[Lennart Poettering]

On Fri, 24.04.15 13:37, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:

> >> 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 ;-)

I am very very un-enthusiastic about the keyscript does. I don't want
to see this upstream. For yubikeys/smartcards I am pretty sure proper
support should be added to the c tools, not via some script glue.

I think DEbian's argument with device before file path certainly makes
more sense, but ultimately I don't really care about the order. WOuld
still be willing to add a patch that adds support for such external keys.

Lennart

-- 
Lennart Poettering, Red Hat