Bug 692258

crypttab was always processed only by initscripts.
And now it is processed by systemd, really nothing to do here (maybe feature for systemd?)

For LUKS, you do not need crypttab at all, metadata are on disk. Storing password directly in crypttab means no security at all.

(In reply to comment #1)
> crypttab was always processed only by initscripts.
> And now it is processed by systemd, really nothing to do here (maybe feature
> for systemd?)
>
> For LUKS, you do not need crypttab at all, metadata are on disk. 

That's not the point. And history of how things used to work or how they currently work wasn't exactly the point either. The point, which you didn't comment on btw, was that it's really counter-intuitive that steps 1. and 2. from comment 0 doesn't work.

> Storing
> password directly in crypttab means no security at all.

If /etc/crypttab is on an encrypted filesystem it's fine doing things like this. Of course, at the end of the day it depends on your threat-model - but saying "means no security at all" is just plain false. Now, it's possible you don't like /etc/crypttab but note that storing the password in this file is explicitly allowed.

I see you closed the bug WONTFIX so that means I'll just write my won /etc/crypttab parser and pipe the password into cryptsetup(8) - yay for code-reuse!

> The point, which you didn't
> comment on btw, was that it's really counter-intuitive that steps 1. and 2.
> from comment 0 doesn't work.

I think that step 1 is not needed - cryptsetup requires device and map name on commandline, so what information should it parse from crypttab? just password? Then use keyfile argument or pipe password to cryptsetup directly.

The /etc/crypttab was workaround before LUKS. I wish it never existed :)

> If /etc/crypttab is on an encrypted filesystem it's fine doing things like
> this. Of course, at the end of the day it depends on your threat-model - but
> saying "means no security at all" is just plain false. Now, it's possible you
> don't like /etc/crypttab but note that storing the password in this file is
> explicitly allowed.

sure, and the crypttab parser is now implemented in systemd (which uses libcryptsetup and should handle all obscure parameters). 
Note there is also "swap" and "tmp=<tmpfs>" arguments - I really do not want fork mkswap or mkfs or whatever from cryptsetup.

> I see you closed the bug WONTFIX so that means I'll just write my won
> /etc/crypttab parser and pipe the password into cryptsetup(8) - yay for
> code-reuse!

And writing another parser into cryptsetup when there is one in systemd isn't code duplication?

I would better get rid of /etc/crypttab completely. (It is not even standard among distros - some support different options).

Debian has wrapper scripts, so maybe unify them and include in upstream cryptsetup. But I really do not want hardcode crypttap parsing in cryptsetup.

(In reply to comment #3)
> And writing another parser into cryptsetup when there is one in systemd isn't
> code duplication?

Well, systemd would use the parser in (lib)cryptsetup. The point here is getting the layering right. E.g. keeping the mechanism where it belongs and not having it in the policy manager just because.

> I would better get rid of /etc/crypttab completely. (It is not even standard
> among distros - some support different options).

I don't like /etc/crypttab either but it's what we have right now. Completely revamping how storage configuration works _is a lot of work_. You can't just solve filesystems in one way (currently /etc/fstab), LUKS in another (currently /etc/crypttab), MD RAID in yet another (currently /etc/mdadm.conf) and LVM in a fourth way (currently some other config files or always started at boot). And multipath and now btrfs with its own volume manager. And probably also things like iSCSI and maybe even FCoE. It's all connected and all have to work together. In particular, you need to express dependencies, you need to ensure that you don't accidentally scan all LUNs, need to ensure that you don't automatically start things (think multiple initiators) and so on. Extremely hard problem. 

(FWIW, I actually started writing bits to solve this puzzle last year (see http://people.freedesktop.org/~david/stc-20101011/stc.conf.html for the unified configuration format) but decided not to pursue it (for the time being) because it's such a hard sell and I'm tired of all the infighting.)

yes, I know all the config files you are describing here and the problems related (I even read your stc.conf proposal long time ago. Not sure if revamping all storage configs is the proper way though.).

But the decision keep /etc/crypttab in initscripts (now systemd) area only was done long time ago.

My focus was to provide volume encryption in LVM - where it logically belongs to - for the typical configuration LVM over LUKS you have it on the same layer. You activate just "encrypetd LV" and not LUKS and PV over it - and lvm metadata can contain additional attributes, similar to crypttab (except passphrase) - idea was to provide interface, one of it could be crypttab parser but more logical is key server or token interface.
(there was testing patches but nothing is integrated yet)

crypttab is not flexible, people want to use encrypted keyfiles (gpg encrypted files), tokens, whatever.