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

[Andrei Borzenkov]

В Thu, 23 Apr 2015 00:48:38 +0200
Lennart Poettering <lennart at poettering.net> пишет:

> On Fri, 20.02.15 10:56, Jan Synacek (jsynacek at 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.

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

In any case it became dracut API which is too late to change.

> 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.

> > 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.

> > Also, there's a problem that I'm not sure how to solve. If the
> > keyfile_device is somehow misspecified (for example, the uuid simply
> > isn't valid), the boot stalls. I believe that this was one of the
> > problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I
> > was thinking about using udev to verify the uuid and its device, but
> > I'm not sure if this makes sense to do in initrd. Any pointers would
> > be appreciated.
> 
> Things like this are necessarily racy: at boot time devices are not
> probed yet, and just start to appear. That means if you enumerate them
> it is highly likely your block device has not shown up yet, but will
> so shortly. Hence you need to wait for them. But that means you cannot
> really distuingish the case "not shown up yet, but will" from "will
> never show up"...
> 
> > Once the above problems are sorted out, an extension of this patch
> > (perhaps another patch?) would be to also support the third argument
> > that rd.luks.key can take in dracut.
> 
> Which is?
> 

LUKS device to which key applies. Can be wildcarded.

> Lennart
>