В Thu, 23 Apr 2015 16:57:09 +0200
Lennart Poettering <lenn...@poettering.net> пишет:
> On Thu, 23.04.15 06:41, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
> > В Thu, 23 Apr 2015 00:48:38 +0200
> > Lennart Poettering <lenn...@poettering.net> пишет:
> >
> > > On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote:
> > >
> > > Sorry for the late review.
> > >
> > > What's the precise background of this? Can you elaborate? Is there
> > > some feature request for this?
> >
> > There are multiple bug reports that switching to dracut with integrated
> > systemd breaks ability to auto-setup encrypted devices using keyfile
> > on external USB stick.
>
> Hmm, but from Jan's mail I got the impression that this is a Dracut
> feature in the first place? Now I am confused?
>
> Which initrd implementations supported this scheme before?
>
Dracut supported it. When it implemented native systemd in intird, it
lost this feature. You can get it back building initrd without systemd
dracut module.
> > > 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?
> > > 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.
keydev is a device on which key file resides. It might be kernel
name of devices (should start with "/dev/"), UUID (prefixed with
"UUID=") or label (prefix with "LABEL="). You don’t have to specify
full UUID. Just its beginning will suffice, even if its ambiguous.
All matching devices will be probed. This parameter is recommended,
but not required. If not present, all block devices will be probed,
which may significantly increase boot time.
If luksdev is given, the specified key will only be applied for
that LUKS device. Possible values are the same as for keydev.
Unless you have several LUKS devices, you don’t have to specify
this parameter. The simplest usage is:
Example.
rd.luks.key=/foo/bar.key
As you see, you can skip colons in such a case.
> > > > First version of the patch that allows rd.luks.key to be specified
> > > > almost the same way as dracut can read it.
> > > >
> > > > The solution creates a temporary mount unit "mnt.mount" that the
> > > > generated cryptsetup service wants. The partition where the keyfile
> > > > is then mounted to /mnt and the absolute path to the keyfile is
> > > > changed so it points to this temporary mount instead.
> > >
> > > Well, I'd place this in /run somewhere. Maybe
> > > /run/systemd/cryptsetup/mount or so...
> > >
> > > > I'm not sure if temporarily mounting something to /mnt in initrd is
> > > > safe. If not, what would be a preffered way to do this?
> > >
> > > What does temporarily mean? When is this unmounted?
> >
> > To fetch keyfile dracut needs to mount USB stick. This mount is not
> > normally needed after cryptomount setup is completed.
>
> Well, sure, I am just wondering what precisely shall be used as
> trigger to unmount it again.
>
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
