Heh. I’ve seen Wayland proponents cite the “impossibility” of screen locking in X11 as a reason to rewrite the entire thing from scratch.
I’ve also seen this argument from the systemd crowd (spoiler alert: the logind ecosystem is also unreliable).
I’ve also seen this argument from the systemd crowd (spoiler alert: the logind ecosystem is also unreliable).
Supposedly Gnome is better but I have no idea.
EDIT: I also found this looking through github issues. It's not only a know issue, it's a WONTFIX:
>> This also brings up a good point. If sway detects that swaylock (or whatever locking process is used) didn't exit cleanly, it should try and recreate it, so we don't just end up giving the a malicious user access to the session.
> I don't think this is worth it
https://github.com/swaywm/sway/issues/2031#issuecomment-3920...
In that PR they changed the render loop rather than implement the "not worth it" suggested solution. At no point was it marked as WONTFIX.
> But if xscreensaver crashes, the screen is unlocked, and our attacker is now logged in as the person who locked their screen.
EDIT: To clarify I meant that jwz' blog post is the one which implies otherwise.
Xscreensaver attempts to mitigate this by being as simple as possible to prevent crashes. swaylock doesn't do this either, apparently. Several crashes have been reported in the past year alone.
I was just expressing disappointment in the lack of interest in fixing #1.
It seems that wayland architecture can solve this only when a compositor directly contains screen locking code. And it also means that every wayland compositor have to do this separately (btw is there any reusable library covering this functionality?) and that independent wayland screen lockers (such as swaylocker) have the same problem as X server implementations.