<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 22, 2017 at 9:19 PM, Guilhem Moulin <span dir="ltr"><<a href="mailto:guilhem@debian.org" target="_blank">guilhem@debian.org</a>></span> wrote:<span class=""></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Basically, the premout script forks dropbear sshd in the background as<br>
soon as possible; by using command="/bin/cryptroot-<wbr>unlock" as<br>
authorized_keys(5) option, users can either enter the password at the<br>
initramfs shell or through ssh.<br>
<br>
I couldn't avoid either searching for askpass through the process list,<br>
though :-/<span class=""><br></span></blockquote><div><br></div><div>Alright. One reason I was asking is because in #debian-kernel they repeatedly said "Don't fork, don't subshell, it's bad". I guess it's good to know it's not just me who had to do it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>The disk name and source are respectively found in the askpass process'<br>
CRYPTTAB_NAME and CRYPTTAB_SOURCE environment variables.<span class=""><br></span></blockquote><div><br></div><div>Huh, don't know why I missed that. Sure is cleaner than what I was doing at any rate.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> is that if clevis fails to get the password and the user enters a<br>
> password manually, then after a while the script will close out the<br>
> subshell saying that sleep can't be found.<br>
<br>
</span>Do you have busybox installed?  It provides sleep, we'll soon split the<br>
cryptsetup package so the initramfs integration can require busybox.<br></blockquote><div><br></div><div>It is: In fact, clevis requires bash to be imported. The reason it might error out with sleep can not be found was that I don't really have a way to tell when the password is unlocked, and at first I didn't exit out after an attempt was made. So, if it wasn't successful and you entered the password as usual, the forked shell would keep trying to loop until initramfs was unmounted. I since changed that though: At first, I was thinking if cryptroot had to decrypt more than one disk. Of course, it doesn't support that anyways, so I just made it so if it detects askpass it exits out.<br><br></div><div>Thanks for the tips.<br></div></div></div></div>