Bug#618862: [systemd-devel] Debian Bug#618862: systemd: ignores keyscript in crypttab - a possible solution

[Alberto Bertogli]

I hit this issue after upgrading a system that used keyscript to Jessie,
and it would no longer boot with systemd [1].

That led me to look into adding a password agent for my use case, and/or
creating a generic one that would invoke keyscripts as a workaround...


On Wed, Feb 05, 2014 at 12:16:00AM +0100, Lennart Poettering wrote:
> On Thu, 30.01.14 10:40, David Härdeman (david at hardeman.nu) wrote:
> 
> > a) getting the name of the cryptdev that the password request
> > corresponds to currently involves parsing the prompt message
> > ("Please enter passphrase for disk %s!") which is obviously not a
> > real solution...
> > 
> > This issue is fixable with minor upstream changes, e.g. by extending
> > the PasswordAgent protocol to add "Subsystem=cryptsetup" and
> > "Target=<diskname>" entries to the "ask.xxxx" file.
> 
> I'd be fine with adding a field "Id=" or so, which then is filled by an
> identifier of some kind be the cryptsetup tool that is useful to
> identify the device to query things on. for example:
> "Id=cryptsetup:/dev/sda5" or so could be one way how this could be
> filled in. We wouldn't enfoce any kind of syntax on this, just suggest
> some common sense so that people choose identifiers that are unlikely to
> clash with other subsystems, and somewhat reasonable to read...

... and I ran into a problem with this, because in practise this field
can look like:

  Id=cryptsetup:ST1234AB567-1CD234 (cbackups) on /var/backups/

for a crypttab line like:

  cbackups /dev/disk/by-id/ata-ST1234AB567-1CD234_1XY2ZWAB-part2 cbackups luks,keyscript=/usr/bin/kxc-cryptsetup


because it comes from the "name", which seems to be constructed for
human consumption, at
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n596

So a password agent _still_ needs to resort to brittle parsing of the
"Id" field in order to find the corresponding crypttab entry.


Would changing get_password() to take an additional id, which would be
the volume name (argv[2]), and use that for the ask_password_auto() id,
be ok with you?

That would allow password agents to have a reliable id to work with
without doing brittle parsing, and matching what's in crypttab.


In theory, existing code should not need to adjust to the change, as the
proposed change is already a possibility when neither the mount point or
description are available, see
http://cgit.freedesktop.org/systemd/systemd/tree/src/cryptsetup/cryptsetup.c#n607
I don't know of any password agents to verify in practise, though.



> > b) the password agent implementation in systemd doesn't seem to
> > handle binary strings (i.e. strings with '\0'), as can be seen by
> > calls to e.g. "strlen()"...
> > 
> > Whether making it binary safe would be a major change or not is
> > something I haven't researched yet but it seems like a change that
> > should be generally useful upstream...
> 
> I'd be OK with this, as discussed at FOSDEM, and I see you already
> posted a ptach for this.

Has this been merged?

Is it safe for a password agent to write content with \0 back to the
socket?

Thanks!
		Alberto


[1]: In case it helps anyone else, I added the "initramfs" option to
crypttab as a workaround, which works in my case because the script
(kxc) is initramfs-ready.