[arch-projects] crypttab key syntax

[Thomas Bächler]

Am 22.03.2012 23:22, schrieb Matthew Monaco:
> Since we're going for systemd compatibility

We are?

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

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

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

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


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

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.

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20120322/3d48b50d/attachment.asc>