[pkg-cryptsetup-devel] any reason why askpas blocks all signals?

[Christoph Anton Mitterer]

Hey David.

Thanks for your reply.

On Wed, 2021-10-13 at 13:41 +0000, David Härdeman wrote:
> I wrote the initial version of askpass. I'm not 100% sure anymore (it
> was a long time ago), but I think the reason all signals were blocked
> is just because it was the simplest way to "deal" with signals (i.e.
> by ignoring them completely) under the assumption that you wouldn't
> realistically want to interfere with askpass as it's (normally) a
> prerequisite for continuing the boot process.

I see.


> I don't think there's any harm in allowing some signals if there are
> use-cases for that.

I'm actually tempted to change the behaviour then as follows:


1) let the default signal handling in place until right before the
passphrase is about to be printed.

Since askpass might also be used under normal userspace (i.e. not in
the initramfs),... I see no reason why signals like STOP or so
shouldn't be allowed and handled in their default way.
Even if the process is terminated by such signal without it's own
custom handler, it should always have a non-zero exit status.


2) Right before the passphrase is about to be printed, I'd block all
signals.
Simply to make sure that no partial passhprase is printed, which might
then be used in plain dm-crypt devices without any checking whether it
was the right key or not.



Any objections to that? :)


Cheers,
Chris.