←back to thread

Apple: SSH and FileVault

(keith.github.io)
507 points ingve | 2 comments | 18 Sep 25 20:15 UTC | HN request time: 0s | source
Show context
Cu3PO42 ◴[18 Sep 25 21:02 UTC] No.45294976[source]▶
Neat. Though I wonder if this suffers from the same race condition that the graphical session does when your shell is stored on a data volume.

Specifically, if you restart and opt to restart apps, they can come up before all volumes have been decrypted and mounted. If your shell is on one such volume, your terminal emulator may fail to start, for example. This can happen when using Nix to install your shell, for example.

I imagine this may be even easier to hit over SSH unless the underlying problem was resolved.

replies(4): >>45295432 #>>45296342 #>>45296948 #>>45297212 #
1. lilyball ◴[19 Sep 25 01:23 UTC] No.45296948[source]▶
Unlock over SSH terminates the connection after unlocking the data volume, so it doesn't even attempt to start the shell until you reconnect after it's fully booted up.

FWIW you can fix the shell issue by wrapping your shell in a shim that essentially runs wait4path on the nix store before exec'ing your real shell. I set up my environment to install that shim binary directly onto the data volume at a known path so it can be used as my login shell.

replies(1): >>45297024 #
2. Cu3PO42 ◴[19 Sep 25 01:34 UTC] No.45297024[source]▶
Depending on the timeouts involved, I imagined it might still happen if you had automatic retry.

And thanks for the pointer, I actually have the same fix in my config with the nice benefit of only adding a single non-changing entry to /etc/shells. It might be worth up streaming something like this to nix-darwin, so we don't all go implement essentially the same fix.