|
|
|
|
|
|
by cbright
4439 days ago
|
|
|
> Who knows what bugs wait lurking in there; who knows which particular combinations of which libraries are a security-bug timebomb. [...] The GTK and GNOME libraries have never been security-audited to the extent that their maintainers would be willing to make the claim, "under no circumstances will this library ever crash." > gnome-screensaver is brand new, bug-ridden, unreliable, and a security disaster waiting to happen Looks like jwz has been vindicated here. References:
http://www.jwz.org/xscreensaver/toolkits.html
http://www.jwz.org/xscreensaver/faq.html#gnome-screensaver |
|
|
However jerking off to discussions about how to properly implement screen locker password input completely misses the point: That locking a screen/session from "inside" always will be flawed. There's an "easy" way to fix it: Instead of trying to lock a session with an inside locker, it should be detached from the terminal instead.
If you're working on just the text console this is a piece of cake: Use tmux or screen for the login shell and as soon as you detach from it you're getting logged out (a lot of people use this setup). There's no way a screen locker crash would pose a security thread, because there's no screen locker at all. Just the regular login which when crashing gets respawned.
Had XFree86/Xorg the capability to detach the X server from the screen, this would allow to log out to the regular display manager login and "unlocking" a session would be simply reattaching to it. Unfortunately the internal driver/device model used by XFree86/Xorg made it hard to impossible to implement such a thing (this is not a drawback of the X11 protocol per se, but the widespread implementations of it).
Luckily Linux is moving to a new graphics model and whatever we'll use in a few years, hopefully detaching graphical sessions will become as simple as using tmux/screen; then you'd close a terminal session instead of locking and no longer need a screen locker.