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

[David Härdeman]

On 2013-06-25 17:47, Michael Biebl wrote:
> Am 25.06.2013 13:13, schrieb Harald Jenny:
>> Dear Michael Biebl,
>> 
>> following the systemd survey and discussion I think these mails might 
>> be
>> of interest to you concerning possible ways to solve the current issue
>> (not only in Debian but also SuSE/upstream interest).
>> 
>> http://lists.freedesktop.org/archives/systemd-devel/2012-June/thread.html#5693
>> http://lists.freedesktop.org/archives/systemd-devel/2012-July/thread.html#5835
> 
> I personally don't own such hardware, and I never have userd
> cryptsetup's keyscript support. So I'm probably not the most qualified
> to evaluate the situation.
> That said, reading the upstream discussion, I guess we have 3 options
> a/ do nothing about it
> b/ apply the patch from David Härdeman downstream and maintaining it as
> a downstream patch forever
> c/ try to implement keyscript support based on the PasswordAgent 
> interface
> 
> a/ is obviously not very compelling. As for b/, we try to avoid
> downstream patches as much as possible.
> Regarding c/, I dunno how much effort that would be.
> 
> Bringing David into the loop here. Maybe he has some further insight on
> this matter.

I found some time to consider how to solve this and I think I have a 
pretty good solution that'd require a minimum amount of changes 
upstream.

What I've hacked together is:

First, a patch to the "askpass" binary in cryptsetup (the Debian 
package, not systemd's own stuff) so that it'll detect that systemd is 
running, in which case it'll use systemd's own password agent system for 
requesting a password from the user.

Second, a new systemd password agent. It waits for a password request 
from systemd's own cryptsetup implementation. The password agent then 
re-parses /etc/crypttab to find the corresponding entry and checks if it 
includes a keyscript= option. If no keyscript option is present the 
agent does nothing but if it *is* present, the agent recreates the 
environment created by the current cryptsetup scripts, launches the 
keyscript and sends the output back via the appropriate socket provided 
by systemd.

That the changes to "askpass" and the introduction of the new password 
agent are unrelated but both are necessary to not break existing 
keyscripts. "askpass" is used in keyscripts to get an actual key from 
the user. The password agent makes sure that systemd's own cryptsetup 
stuff honors the keyscript.

The new agent is not production ready yet (I plan to do some more work 
on it during FOSDEM), the two most important issues are:

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.

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



Minor detail: the additional agent could be shipped either in (I have no 
real preference):

a) the cryptsetup package

b) as part of the Debian systemd package

c) upstream systemd


Feedback welcome.

Regards,
David

[1] http://www.freedesktop.org/wiki/Software/systemd/PasswordAgents/