[arch-projects] crypttab key syntax

[Matthew Monaco]

On 03/22/2012 04:57 PM, Thomas Bächler wrote:
> Am 22.03.2012 23:22, schrieb Matthew Monaco:
>> Since we're going for systemd compatibility
> 
> We are?
> 

I've been discussing this with Tom and Dave. I thought you'd caught wind.

>> we're going to need to change the
>> key syntax.
> 
> You have a strange idea of what we NEED to do.
> 
>> It seems like there are two supported syntaxes which are handled a
>> little bit differently by the encrypt hook and initscripts.
>>
>> 1) <dev>:<fstype>:<file>
>>
>>    I want to support this by adding a keydev= option.
> 
> We have an option for this. Is there any sane reason to change it?
> 
>> What remains is what to
>>    do when a key is not available and there is no keydev=. For a first go I
>>    think such a setup doesn't need to be supported, but eventually deriving a
>>    default will be good.
> 
> I have no idea what you are talking about. Please, make some sense.
> 
>>    The primary target here is to support having a keyfile for an encrypted /usr
>>    stored on root. This is a little tricky in the initcpio because it would be
>>    pretty undesirable from my perspective to tell the user such keys need to be
>>    /new_root/...
> 
> I made it a point not to support such setups - people need to do sane
> things when doing encryption - this doesn't sound sane.
> 

I don't use a separately encrypted /usr. But chainlinking it by storing the key
seems reasonable if you don't want to enter two passwords and don't want to use
a LVM.

>>    One way to do this would be keydev=/dev/mapper/root, but this might mean
>>    mounting root to some temporary location, unmounting it, and then having
>>    initcpio pick up as normal after the hooks. Among other things, this would
>>    mount root before fsck.
> 
> If you really want to support this, you need to go further - you need to
> change more of the architecture in early userspace.
>

I know, I have a mkinitcpio branch for playing around with it.

>> 2) <dev>:<offset>:<length>
>>
>>    I want to drop support for this. The length field is supported by
>>    cryptsetup's --keyfile-size option.
> 
> You actually have no idea how this is supposed to be used. You can store
> a key on a USB drive in the unused space between partition table and the
> first partition. This way, you can store a key without anyone noticing
> it is there.
>

No, I wasn't aware. Thanks.

>>    I don't see <offset> being widely used as its not even documented.
> 
> It is used in the wild, I am pretty sure of this.
> 
>> Coupled
>>    with systemd not supporting anything like this, I'd like to cowardly refuse
>>    to implement it.
> 
> Yes. First we start implementing things because systemd implements them.
> And now, we stop supporting things because systemd doesn't support them.
> What are we, the slaves of the systemd imperium?
> 

Like I said, I didn't know the use-case. I don't use systemd much, but when I
want to try it out, I don't want to have to edit my crypttab file. It's a shame
there isn't some standard already, but the strongest version of crypttab comes
from Debian. Systemd supports a subset of this format.

> 
> It seems like I lack some context here. But as you start your mail
> without any context, it is clear you were not planning to give any. What
> is the motivation for this mail and where do all these things we need to
> and don't need to do come from?
> 
>
> Now the important part: Keeping a broken, unsuitable and
> non-standardized format like crypttab is plain stupid. A
> one-line-per-container file format cannot even begin to contain all the
> options that people want to use.
> 
> Over the years, people wanted to:
> 1) Open containers via passphrase.
> 2) Open containers via keyfiles.
> 3) Open containers by using raw areas on block devices of all kinds.
> 4) Use random keys to create a new container and
>    a) Create a swap space on it
>    b) Create a fresh file system on it and mount that somewhere
>

smartcard

> Those are just the things I remember off the top of my head, I am pretty
> sure there was more. And you are planning to push this all into the
> one-line-per-container crypttab. Even worse, you are planning to drop
> some already existing features, because you CAN'T put them all into that
> format.
> 

I don't want to drop any used features except for storing the literal password
in /etc/crypttab. Exotic setups might be a little clunky but I think they can
all be supported on a single line.

> A proper way to solve this would be a directory with proper
> configuration files, one file per container. You would then be free to
> support all interesting options and have enough flexibility to add more
> options later.
> 
> Staying with crypttab will only give you a half-baked solution, and you
> will end up having to close most feature requests you get, because
> extending the format will be nothing but a pain in the ass.