The other big problem is that all your processes continue running, but your disk is unmounted. I can't imagine how you'd avoid everything crashing horribly.
I mean, I can imagine an implementation where the system pauses all processes related to the user session _except_ the screenlocker, and have a custom screen-locker which can supply the credentials to luks…
But that the screen locker is a desktop application, so the compositor itself needs to stay alive too, but then compositor might try to talk to other applications, and those are frozen. So wouldn't it consider them crashed and disconnect them? Now your compositor needs to understand that the system is in a "disk unmounted and processes frozen" state too.
Not even sure how you'd deal with logs from its stdout, since the file descriptor to the log files is invalidated too.
If anyone is actually using such a setup, I have so many questions. I know that theoretically all this is feasible, but all the existing components don't seem to be ready for just unmounting the encrypted disk at runtime like that.
Do you mean with with current software? How to avoid it in general is straightforward.
If you're the only one with the disk password then the simple answer is make both passwords the same and make the different parts of the system communicate better.
If you want multiple users, give them each a different boot password and encrypt a separate copy of the disk key with each one. That password can be their login password too, or it can encrypt their login.
I have always been thinking LUKS was supposed to be enrolled in TPM, so you should not have to enter this key manually; this is just to prevent someone from unplugging the hard drive and reading on another machine. Of course, this depends on one's threat model.
I mean, I can imagine an implementation where the system pauses all processes related to the user session _except_ the screenlocker, and have a custom screen-locker which can supply the credentials to luks…
But that the screen locker is a desktop application, so the compositor itself needs to stay alive too, but then compositor might try to talk to other applications, and those are frozen. So wouldn't it consider them crashed and disconnect them? Now your compositor needs to understand that the system is in a "disk unmounted and processes frozen" state too.
Not even sure how you'd deal with logs from its stdout, since the file descriptor to the log files is invalidated too.
If anyone is actually using such a setup, I have so many questions. I know that theoretically all this is feasible, but all the existing components don't seem to be ready for just unmounting the encrypted disk at runtime like that.