[Pkg-systemd-maintainers] Bug#618862: systemd: ignores keyscript in crypttab

[Christoph Anton Mitterer]

Hi.

Had a private conversation with Tollef and he pointed me to this bug...

Even though it may be obvious to any developer, let me add the
following:
I had a short glance at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n54
I guess another crypt_activate_by_? function would need to be
implemented for keyscripts.

One thing which need to be taken into account is the following:

The keyscript is an arbitrary program (no necessarily a shell script...
and the key file parameter (the 3rd field in crypttab(5)) may _not_ be a
pathname at all.
I for example use a keyscript for openpgp encrypted keys (a different
one from that shipped in Debian, which has several functionality
deficiencies and following from that: security issues) where one would
see lines as the following in crypttab:

root   /dev/disk/by-uuid/74b4564a-728e-11e3-8a8d-502690aa641f   device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root   loud,luks,keyscript=decrypt_openpgp,tries=0

All of this is "normal" unless the 3rd field:
device=/dev/disk/by-uuid/0faa9776-ccbe-4834-a853-501eb3b75372:pathname=/etc/dm-crypt/keys/someHost_root
which is given to my keyscript decrypt_openpgp

It basically combines two options (separated by a colon) into the one
passed to the keyscript (which splits it again)...
device= being a filesystem which the keyscript should wait to appear
(i.e. a USB stick)... mount it ... and
pathname= being a a file local to the filesystem on that device... which
is then read, fed through gpg and so on.

And this is just one example where one could need multiple options put
together in the keyfile field of crypttab - unfortunately the Debian
maintainer refused to standardise this.

Another example could be a OpenPGP crypto smart card, where one waits
for a specific smart card ID to appear, and reads key number n from it.
Or one can think of examples where the key is read via secured network
connections (ssh, ipsec, whatever) and where multiple parameters would
be required.


So the point is... any support for keyscripts in systemd MUST NOT try to
be smarter than it should and somehow interpreting or modifying the
keyfile field.
It simply MUST pass that on the the keyscript, just as the Debian
cryptsetup scripts do it.

And it should be noted, that the cryptsetup scripts initialise a bunch
of environment variables for the executed keyscript program, which of
course systemd would need to do as well.


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5165 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140101/c48b9100/attachment-0002.bin>