[arch-projects] crypttab key syntax
dgbaley27 at 0x01b.net
Thu Mar 22 19:18:17 EDT 2012
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
> 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
>> 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.
>> 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
> 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
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.
More information about the arch-projects