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. >> > > > Is this specific to Dracut so far? Is this widely used, and something >> > > > that we really want. >> > > >> > > I can say about dracut only but yes, it is used and it is serious >> > > regression when it is used comparing with pre-systemd version. >> > >> > Can you point me to documentation about the previous features in this >> > regard? Which initrd implementations are you referring to? >> >> Sure, in dracut manual page: >> >> crypto LUKS - key on removable device support >> rd.luks.key=<keypath>:<keydev>:<luksdev> >> keypath is a path to key file to look for. It’s REQUIRED. When >> keypath ends with .gpg it’s considered to be key encrypted >> symmetrically with GPG. You will be prompted for password on boot. >> GPG support comes with crypt-gpg module which needs to be added >> explicitly. > > To make this clear: the gpg support is crazy. I don't want to see that > in systemd at all. > > Also, so far we don't allow <luksdev> to be specified for any of the > other options, such as luks.options or so. I am not convinced we > should support that here. > > I'd be willing to merge a patch that supports basic > rd.luks.key=<keypath>:<keydev>, even though I think it's usecase is > more security theater than really useful. > > But please put the temporary mount into /run, keep it minimal, define > a clear trigger to unmount it, no gpg, no <luksdev> support. > > Lennart > > -- > Lennart Poettering, Red Hat > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- 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
