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

[Jan Synacek]

Andrei Borzenkov <arvidjaar at gmail.com> writes:

> В Fri, 20 Feb 2015 10:56:41 +0100
> Jan Synacek <jsynacek at redhat.com> пишет:
>
>> First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can
>> read it.
>> 
>
> This sounds like working around dracut bug. Dracut already has code to
> deal with it, it updates /etc/crypttab and reload systemd to run
> generators but it completely ignores keyfile parameter in non-systemd
> branch.
>
> The code in dracut for systemd-enabled case does
>
> echo "$luks $dev - timeout=0,$allowdiscards" >> /etc/crypttab
>     systemctl daemon-reload
>     systemctl start cryptsetup.target
>
> which means it won't even use keyfile anyway.
>
> Why do not you simply mount device here? Dracut already has code to
> temporary mount keyfile device in non-systemd-enabled case, you can
> simply reuse it.

I've done some digging around and...

I don't get it. It makes sense to put the functionality to dracut, so
why is this implemented *differently* in both dracut and systemd? Why is
there code to make this systemd-independent task in a systemd-enabled
and non-systemd-enabled case? It's quite confusing.

>> 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.
>> 
>> 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?
>> 
>
> Dracut creates unique name for it already.

Ok, I found the code. Thanks for the pointers!

>> 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.
>> 
>> 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.
>> 
>> Jan Synacek (1):
>>   cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
>> 
>>  src/cryptsetup/cryptsetup-generator.c | 163 +++++++++++++++++++++++++++++++---
>>  1 file changed, 150 insertions(+), 13 deletions(-)
>> 
>

-- 
Jan Synacek
Software Engineer, Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150224/fbe8eee1/attachment-0001.sig>