On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote: > On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote: > > On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote: > >> The raison d'être of wait_for_dropbear() is to avoid handing the > >> execution over to init(1) with a running ipconfig process or unclean > >> network stack. This is what the race condition described in #943459 is > >> about. wait_for_dropbear() somewhat of a hack, but ipconfig doesn't > >> seem to react to SIGTERM and I couldn't do better at the time. > > > > How about SIGKILL, then? > > No.
Why no? > > The user has more knowledge than initramfs. For instance, he knows > > whether the link is present. And he generally knows the typical > > time he has to wait for the DHCP server (unless a major problem > > occurs with the server, in which case he may have to wait any time). > > So it's better to leave the control to the user. > > I could certainly make the timeout configurable, but that's be an option > hardcoded in the initramfs (or the kernel command line) so probably not > ideal to manually flip occasionally when the users knows there is no > link present. If you let the user run a script that controls the timeout, that would be better. For instance, a typical setting when dropbear is used to unlock the disk(s) would be to set the timeout so that the following conditions are *both* satisfied: 1. Some lower bound has been reached (say 10 seconds). 2. The passphrase has been validated. This makes sense because in this case, it is useless to abort wait_for_dropbear() while the passphrase has not been validated yet. Then there are 2 cases: 1. The user is in front of his machine. He also knows whether he should get an answer from the DHCP server. Then, depending on the context and the messages from the DHCP client that appear on the screen, he can validate his passphrase ASAP (e.g. because there is no link, so that there cannot be an answer from a DHCP server) or wait for the DHCP server to answer (the user may be the admin of the DHCP server, e.g. for a machine at home, so that he will know what to do). 2. The user is not in front of his machine, which may be far away. The only solution is to unlock the disk(s) via SSH. Since the user cannot type the passphrase, there will never be a timeout (due to condition 2), which is exactly what the user wants. Note that with these rules, condition 1 is even normally useless. It may only be useful to avoid a mistake from the user, or if the user has confidence that it will always work in practice (if the chosen value is large enough), so that the user would validate his passphrase ASAP. BTW, I've just noticed that the timeout introduces a second annoying regression: If there is a temporary issue with the DHCP server just after the machine has been restarted, so that the timeout is reached, the user will not be able to unlock the disk until he can go back in front of his machine! My proposal would solve this issue. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
