Re: [PATCH] 90crypt: keys on external devices support

[Mr Dash Four <mr.dash.four-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]

> '-I' option are for user to include single files.  If you'd like to
> merge files into initramfs with its dependencies, you use '*inst*'
> family functions.  See 'dracut-functions' file.
>   
Thanks, I'll have a good look.


> First of all rd_LUKS_KEYDEV_UUID will be changed to 'rd.luks.keydev' and
> allow to specify devices by filename in /dev, LABEL or UUID.
>
> It's done a bit more flexible.  You can specify 'rd_LUKS_KEYDEV_UUID'
> (later 'rd.luks.keydev') and 'rd_LUKS_KEYPATH' (later 'rd.luks.keypath')
> several times.  For every 'rd.luks.keydev' ALL 'rd.luks'keypaths' are
> checked.  I know that such approach have some flaws.  I'll consider your
> proposition (quoted below) for specifying that.
>
> [...]
>   rd.luks.key=<key_path>:<key_dev>:<luks_dev>
>
> Why this order?  <key_path> is always required (obvious).  <key_dev>
> doesn't have to be required, because it's easy to perform search for
> device (and it's done know, it works pretty well, at least with my
> latest not yet accepted patch which needs more improvement :-)).  The
> last is optional too.  Forcing user to write down all UUID-s is not
> ethical. ;-)  It should be automated as far as it makes sense.
>   
Bugger, I forgot about drive labels :-\

In which case using separate rd.luks=<luks_dev> (for password 
identification), rd.luks.key for external dev/key authentication and 
rd.luks.token for token authentication makes sense. I would reverse the 
order though.

The way I see it if you reverse the order to be 
<luks_dev>:<key_dev>:<fs>:<key_path> (don't forget the file system, 
otherwise how would you know how to mount it to read the key - you may 
'assume' that it is either ext2/3, but it might be something else - HFS, 
ReifeiserFS etc.) it makes it more consistent with the Fedora's own 
Kickstart options (see http://fedoraproject.org/wiki/Anaconda/Kickstart 
- scroll further until you find 'ks=').


> Examples:
>   rd.luks.key=/some/file.key:LABEL=cool_keys:UUID=00aabc
>   rd.luks.key=/some/file.key::UUID=00aabc
>   rd.luks.key=/some/file.key:LABEL=cool_keys
>   rd.luks.key=/some/file.key
>
> And probably I'll introduce this scheme in patches I'm improving
> recently.  Does it satisfy you? :-)  And for token it would be:
>
>   rd.luks.token=…
>
> Might be?
>   
I'll be happy if you reverse the order and add a file system type as 
well - it makes it more consistent with the Fedora Kickstart format, 
otherwise is a bit confusing.



>> I've looked through the dependencies and the package scripts though
>> there are, among other things, udev rules and config files, which
>> could complicate matters. Following this I have another query: Does
>> dracut have (at least read) access to the /boot partition where the
>> initramfs image is?
>>     
>
> No, no.  You don't need access to /boot.  You put everything in
> initramfs using installation functions provided by 'dracut-functions'.
> See 'install' and 'check' scripts in some module's directory.
>   

That could spell trouble as for just running pkcs11-tool that requires 2 
configuration files which reflect the specific token type and various 
parameters. Although 90% of all cases fall into the 'default' mode 
scenario there are the rest 10% which do not and have to be properly 
catered for.

The parameters and attributes in these files are complex and cannot be 
specified in the kernel command line in grub.conf. If these 2 
configuration files are embedded into initrd they cannot be changed, 
which means that initrd has to be custom-built for each client 
configuration which makes this whole exercise largely impractical.

The other possible scenario, as I already mentioned, is to use 
configuration files which are outside initrd (separate device or located 
in /boot are two possible alternatives)

One other query related to this: if I want to use crypttab for my root 
(/) partition how is that handled by dracut?