Can anyone explain why a crash in xscreensaver results in the computer being unlocked?
It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.
KDE has a failsafe mechanism. If the screen locker has crashed, it shows a black screen of death with a huge error message.
> The screen locker is broken and unlocking is not possible anymore. In order to unlock, switch to a virtual terminal (e.g. Ctrl+Alt+F2), log in and execute the command: "loginctl unlock session c2". Afterwards switch back to the running session.
That might be a kde limitation in general. The amount of "fun" I had dealing with two screens on kde is outright endless. Not sure they even test that kind of configuration, 640x480 pixels should be enough for everyone.
Now imagine they're powered by a docking station, you go into suspend, put the laptop out of the docking station, wake it up and - tadaa! This bug dissappeared but still occurs slightly diffrent for other people. Three monitors itself aren't more edgecase than 2. How long are you using this setup?
Besides screenlockers, having 2 screens with diffrent resolutions is way worse in KDE than in GNOME. (On X11)
I don't believe the X system had/has a separate protocol for screen locking, or if it does, that any of the programs implement it. So xscreensaver is just another X client that happens to draw itself full-screen on top of all other apps and grab all user input.
From the point of view of the display manager, a screensaver/screenlocker crashing is just a simple app crash. There's nothing in the protocol to suggest that this is a security failure.
jwz wrote a document explaining why this is hard. (Note that this link may result in an unsavoury redirect if you click on it from here. You can, e.g. copy and paste it to avoid this.)
> and re-launch it if it crashes without first signalling that the desktop has been unlocked.
Might be better to just exit the session or load a minimalistic replacement lock program (like the original xscreensaver) to avoid an infinite crash loop.
I believe that's how JWZ's XScreenSaver works, but every distro decided to re-invent the wheel there for whatever reason, then blame it all on X11 when it inevitably fails.
It seems like this whole class of bugs could be fixed pretty easily by having a simple process watchdog run xscreensaver as a child process, and re-launch it if it crashes without first signalling that the desktop has been unlocked.