Bad design in X11 which can't be fixed.
The concept of screen lockers is having a special layer, that can't be bypassed, which a locker creates. The whole security then hinges on the locker not crashing. X11 does have such a layer. Wayland compositors also implement it through such a layer. And for either the situation is, that if the locker crashes, that layer is destroyed by implication and the session exposed.
That's a flawed concept.
What you really want is detachable graphics session. On the text console one can effortlessly use screen or tmux and to "lock" the session simply detach and exit to the regular login getty.
You want exactly the same, but for X11. And there's no obstacle in printiple to implement this. It's just that the Xorg server can't detach. Almost all of the required code is there, fundamentally it'd be the same code that's executed during a VT switch.
In the meantime one can use Xpra with Xvfb to create detachable X11 sessions, which then however lack GPU acceleration.
Mac OS almost gets this right, except it annoyingly defaults to sharing the remote session with the local console unless someone is already logged in locally.
Maybe using Xdummy instead of Xvfb would work better?
This wiki article makes such an approach look promising: https://xpra.org/trac/wiki/Xdummy
Expressed otherwise: just because someone’s written one piece of bad software for Wayland doesn’t mean Wayland doesn’t allow you to write good software. (Whereas I get the impression from what I’m reading that X makes it impossible to write a good screen locker, if by that you require that it be crash-proof and use the usual platform toolkit for the UI.)
(Remember in this that I’m saying I don’t know. I’d like to hear if Wayland does have a good answer to this, or from anyone with definite knowledge that it doesn’t.)
a) there's no Xserver concept of a lock screen which would be hard to fix, I suspect. How would you signal X to lock/unlock; what would it do if the lock client wasn't connected, etc.
b) there's no atomic way to transfer mouse/keyboard grab to another window, which means you can't have a reliable, crash reduced screen locker that supervises a beautiful password checking program; it has to be the same program. This could probably be fixed with an X extension; yes, an extension is a lot of work, and yes, you'd have to deal with fragmentation, but you could keep the untoolkited password dialog in case the extension isn't present, nobody would see it unless they did something odd, so it's fine.
Another issue is that I think I've seen some linux systems don't launch the screen locker until resume, instead of locking before suspend; that's not ideal, because the screen locker will take time to launch and lock the screen (more so if it's got a fancy initialization routine and is a large binary/many libraries to load).
An option could be running a dedicated screen lock Xserver on a different VT, and (securely) switching to that one somehow. But that would probably involve changes to multiple layers at the same time, which is hard to pull off in Linux. People would complain about the bloat of running a second Xserver, regardless of the actual bloat or imcreased utility.
Why not just require that it is there? Is there even a valid reason for someone to keep the extension out unless it is to give another "this is the reason X sucks" speech?
Also, because of piecemeal releases, and remote X. You might update Xscreensaver, but not your X server or desktop environment. You might have a dedicated X terminal which can't easily have its server component updated, but you run remote sessions that have an updated Xscreensaver. (Btw, if you do this, you're pretty dedicated in 2021)
This particular issue is fixed in logind, when you ask it to lock the season/suspend/hibernate it first calls the lock screen, wait it to signal it finishes and them it proceed to suspend/hibernate.
Not saying you need systemd to fix this issue, but it is one of the things that systemd allows you to do correctly without reinventing the wheel.
Its not an X11 problem.
(using bit.ly because he gives a testicle if referrer is HN :P)
- https://www.jwz.org/blog/2021/01/i-told-you-so-2021-edition/
- https://www.jwz.org/xscreensaver/toolkits.html
[Edit]: I understand now. My browser doesn't send referrer URLs, and I think that's the real fix instead of using something like bit.ly!
https://brave.com/privacy-updates-5/
edit: see also: https://www.cookiestatus.com/brave/#referrer
Just tested in Chrome and it works there as well.
I wonder why someone would setup a "bad result" for specific referrers ...
Can't count on everyone having referrer turned off
> X11 ... was designed with no security to speak of, and so lockers have to run as normal, unprivileged, user-level applications. ... This mistake of the X11 architecture can never, ever be fixed.
He also claims in the second post that Xscreensaver is actually vulnerable to exactly the same kind of attack:
> The xscreensaver daemon is a critical piece of security software. The reason for this is that, as a screen locker, any bug in the program that causes it to crash will cause the screen to unlock. As soon as xscreensaver is no longer running, the screen is no longer locked. Therefore, great care must be taken to ensure that the daemon never crash.
Which can be found via this thread: https://news.ycombinator.com/item?id=11412081 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#400
They do nothing fancy - paint a window over everything and wait for the password to be typed in. No animation. No graphics. No anything. No enter unlock password dialog. I am sure there could be some edge cases but I'm having a hard time identifying them.