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

[Lennart Poettering]

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?

What does this actually do? Is the specified key file read from the
specified device? The order of keyfile:device sounds weird, no?
Shouldn't it be the other way round?

Is this specific to Dracut so far? Is this widely used, and something
that we really want.

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

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

Lennart

-- 
Lennart Poettering, Red Hat