In the interest of maximizing battery life, I’ve set up suspend-then-hibernate on my laptop. Using a discrete window manager, so I have a systemd unit that locks the screen when I close the lid. After an hour, it automatically goes into hibernation.
All is well, until I have to boot up from hibernation. I’m prompted to unlock LUKS, then I’m hit with a redundant lock screen once resumed. I’ve tried setting up systemd units referencing suspend-then-hibernate.target and hibernate.target, but I can’t get it to kill the screen locker when resuming from hibernation only, so I don’t have to type in my password twice. Is there any way to have systemd discriminate between the suspend and hibernate parts of suspend-then-hibernate?
How so? The lock screen is to prevent physical access while you’re away, and an attacker can’t kill it without having access in the first place. Any process that can kill it would already have access to your session.
Not all processes that can send a kill signal to another process have the same degree of access as physical access. The fact they are already running inside the session doesn’t automatically imply they have unrestricted access. In fact, you could argue no access at all a process has can compare to physical access. So that’s quite an escalation.
I don’t follow your thought process. I didn’t say every running process could kill the lock screen or if it can kill the lock screen it can access everything else, I said any process that kills the lock screen has to be running. And as the attacker with physical access doesn’t know the password they can’t run anything to kill the lock screen. The only way for them to unlock it is if they already have malware on the device, in which case their physical access isn’t the cause of the problem.