On 24 April 2015 at 10:06, Lennart Poettering <lenn...@poettering.net> wrote: > On Thu, 23.04.15 21:04, Dimitri John Ledkov (dimitri.j.led...@intel.com) > wrote: > >> On 23 April 2015 at 13:08, Lennart Poettering <lenn...@poettering.net> wrote: >> > On Thu, 23.04.15 19:33, Andrei Borzenkov (arvidj...@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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
