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/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
