[systemd-devel] Thoughts about /etc/crypttab keyscript options

David Herrmann dh.herrmann at gmail.com
Thu Aug 14 11:09:05 PDT 2014


Hi

On Thu, Aug 14, 2014 at 7:44 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-devel at zugschlus.de) wrote:
>
> Heya,
>
>> I have read the thread (from 2012?) where those things were discussed
>> here and I understand that I should replace my keyscript with a
>> passwort agent. Things would then work like this:
>
> There's currently no streamlined support for stacking password questions
> really. You currently cannot "take possession" of specific password
> questions.
>
> Also note that we really should redesign the entire scheme around the
> kernel keyring as only transport for the keys (and the bus for
> signalling). I am a bit conservative in changing here too much for now,
> because we really should figure out that bit first.

The hack you describe here should work, however, it's really an ugly
hack. One thing you really need to take care of is to not cause
recursive loops. That is, if your agent places a new *.ask file, it
will be called on it again and *must* ignore it. Otherwise, you end up
with an endless loop.

Anyhow, I don't think we should support stacked agents. Agents are
meant as an API to interact with users. They should not employ any
logic/rules regarding the query itself. They're solely meant as GUI.
That is, to solve your problem, I'd recommend to make systemd allow
external scripts like "keyscript=" before placing *.ask files (or some
other hookup or configuration, if scripts are not suitable for that).
I have never worked with crypttab, though. I have to refer to Lennart
here to tell whether that makes sense. I just want to make clear that
once you query the ask-password tool, you will inevitably end up
forwarding that request unchanged to an UI.

Polkit provides .rule scripts for that. We don't have any equivalent
for ask-password. I'm not sure whether that would make sense.

Thanks
David


More information about the systemd-devel mailing list