[pkg-cryptsetup-devel] any reason why askpas blocks all signals?
Christoph Anton Mitterer
calestyo at scientia.net
Mon Oct 11 22:35:01 BST 2021
On Mon, 2021-10-11 at 23:18 +0200, Guilhem Moulin wrote:
> FWIW I'd be interested to have an opt-in configurable timeout builtin
> inside askpass, with a configurable trigger poweroff / suspend /
> exit() / whatever.
Poweroff/suspend doesn't seem like functionality that would belong into
askpass?
I had also thought about integrating an (exit()-)timeout (like in
passdev) into askpass, but then I thought keep it simply keep it save
and that we have already timeout(1) for that purpose...
> This would solve #970224 and #994682.
Hmm at least the 994682 sounds a bit tricky... wouldn't that mean that
cryptroot has to take care that any possibly already started devices
are properly stopped again.
Plus, what if the system in question powers on because of e.g. some
periodic wake on lan.
In that case one might end up in an startup/shutdown cycle (which might
not be that good for hardware either).
> Not super keen to configure it
> via crypttab(5) options though: I guess one would want the same
> timeout
> & trigger action for all devices anyway, and I'd prefer to avoid
> adding
> new generic options which other crypttab consumers don't understand
> and
> might conflict later.
I for my case would allow two different configurable timeouts (well
actually three):
- one for passdev, with which I read the OpenPGP encrypted key
- one for askpass
- one that serves as default for the above
That makes some sense because of:
- for passdev I could allow ultra long timeouts (actually my keyscript
uses 0/infinity per default, as there's no point to let it fail for the
root fs)
- for askpass however, they encrypted key file is already in memory and
I want some shorter timeout so that the scripts gets killed and the
(still) encrypted key removed from memory
Anyway... do you oppose the idea of making askpass interruptible?
Cheers,
Chris.
More information about the pkg-cryptsetup-devel
mailing list